Environments

Environments in Phase represent the stages of your development workflow. They live inside Apps and hold Secrets that are specific to that stage — such as development database credentials, staging API keys, or production configuration.

How Environments Work

Each Environment within an App is an isolated container of secrets. The same secret key (e.g. DATABASE_URL) can exist in multiple Environments with different values — allowing you to maintain separate configuration for each stage of your workflow without any overlap.

Environments also serve as the finest-grained unit of access control. Users can be granted access to specific Environments within an App, so a developer might have access to Development and Staging but not Production.

Default Environments

When you create a new App, Phase automatically initialises it with three default Environments:

These defaults provide a standard structure that works for most projects. You can rename, remove, or add additional Environments to match your specific workflow.

Custom Environments

Beyond the defaults, you can create custom Environments to match your development process. Common examples include:

• QA — Dedicated quality assurance testing
• Preview — Short-lived preview or feature-branch deployments
• DR — Disaster recovery configuration
• Local — Shared local development overrides
• CI — CI/CD pipeline-specific configuration

Naming Rules

Environment names must follow these constraints:

• Can contain: letters (a-z, A-Z), numbers (0-9), hyphens (-), underscores (_)
• Must be between 1 and 32 characters long
• Must match the pattern: ^[a-zA-Z0-9\-_]{1,32}$

Choose descriptive names that clearly communicate the purpose of each Environment to your team.

Folders and Paths

Within each Environment, secrets can be organised into folders using a path structure. This is useful for grouping related secrets:

/                         # Root path
/frontend/                # Frontend-specific secrets
/backend/                 # Backend-specific secrets
/backend/payments/        # Payment service secrets

Paths are used in secret referencing to access secrets in specific folders, and when fetching secrets through the CLI, SDKs, or API.

Access Control

Environment access is the most granular level of access control in Phase:

• Organisation Owners and Admins have access to all Environments by default
• Developers are granted access to specific Environments when they are added to an App
• Service Accounts are scoped to specific Environments when added to an App

When a user is added to an App, you select which Environments they can access. This can be updated at any time by users with the required member-management permissions.

Environment access can be granted per-user or collectively via Teams. When a Team is granted access to an App, that access is scoped to specific Environments, and Phase automatically provisions environment keys for every team member — including members and service accounts added to the team later.

Environments and Integrations

Each Environment can have its own set of sync integrations. When secrets in an Environment are updated, all connected integrations for that Environment are automatically triggered. This means you can configure Production to sync to AWS Secrets Manager while Development syncs to a local Docker setup.

Managing Environments

Environments can be created and managed through the Phase Console, the CLI, or the API.