Environments

An environment is the first segment of every secret path and the highest-security discriminator. Unlike a naming convention, it's a real, validated object: you can only write to environments that exist.

Defaults#

Four environments are seeded automatically the first time you open the section:

dev · test · staging · prod

dev is the default environment: projects fall back to it, and it opens first. These cover most teams out of the box. The list is always shown in this order, with custom environments after it.

Custom environments#

Under DevOps → Environments you can add your own — for example prepro, qa, or sandbox.

• Codes must match ^[a-z][a-z0-9_-]{0,31}$ (lowercase letter first).
• system is permanently reserved and cannot be used.
• Codes are immutable once any secret uses them (values are cryptographically bound to their full path). You can rename the display name freely.

Requires the secrets:environment:manage permission (organization plans); the Developer owner has it implicitly.

Enable / disable#

Toggle an environment off to freeze it:

State	Writes (new secrets/namespaces)	Reads
Enabled	allowed	allowed
Disabled	rejected (403)	still allowed

This is useful to retire an environment without losing access to its history, or to lock an environment during a migration.

Disabling stops every write to it — your pipelines included — so the console asks you to confirm, and for a production environment to type its code. Projects that used it as their default move to the default environment.

Two environments cannot be disabled: the default one (projects fall back to it), and the last enabled one (with none left, no secret could be written anywhere).

Deleting an environment#

An environment that never held a namespace — a typo like prdo, say — can be deleted outright from its row. One that ever held secrets can only be disabled: its code is part of how those secrets were encrypted, so it has to keep existing for as long as their history does. The default environment and the last enabled one cannot be deleted either.

Sharing across environments#

Environments are isolated by default, and that isolation is the point: a permission naming dev cannot reach prod, however the path is written. There are two ways to cross the line, and they answer different questions.

One secret, many environments → use shared#

If the same value is needed in dev, staging and production — a monitoring key, a registry credential — do not copy it into each environment. Store it once in the shared project and let every environment read it from there. One value, one place to rotate it.

One permission, many environments → list them, or use a wildcard#

If the access spans environments but the secrets are per-environment, you have two options:

You write	It means	Needs crossEnvironment
acme-web/dev/**, acme-web/test/**	exactly those two environments	no
acme-web/*/**	every environment, production included	yes

Listing the environments you mean is almost always the better answer. One permission can hold several paths, so "dev and test, nothing else" is a single permission — and it stays correct when someone adds a prod-eu next year, which a wildcard would silently swallow.

What a machine can see#

A machine's view of your space is filtered by what it actually holds. pulsvault envs lists the environments its permissions can name, not every environment you have — so a key scoped to dev is not told that prod exists. The same applies to pulsvault projects.

Related#

• Namespaces
• The Shared project
• Default permissions
• Access policies
• Paths, plans & roles