Environments

An environment is a deployment target inside a project. You deploy a service into one environment, and the environment's mode decides which keys may touch it.

#What an environment is

An environment's path is orgs/{org}/projects/{project}/envs/{env}, and its id starts with env_.

The slug is a short lowercase name, unique within the project. The slugs the platform's own tooling uses are production, staging, development and preview.

#Mode

mode is live or test. A key's mode must match the environment's mode, so a test key cannot touch a live environment.

Of the usual slugs, only production maps to live mode.

#Listing and managing environments

sylphx access envs list

The command takes the project from the project you are linked to. The client library reads the same path with the same key, so the command, the call and the library return the same environments.

Listing is what is served on the one API today. A project's environments are created with the project (production and preview), and managed through the project routes: GET /v1/projects/{id}/environments and PATCH /v1/projects/{id}/environments/{env_id}. The create, update and delete commands of sylphx access envs are in the CLI's command list, but the one API does not serve them.

#Secrets live in an environment

A secret and a binding to it live in one environment: a Secret and a SecretBinding belong to a single environment, and a binding delivers a value to a workload in that same environment.

A binding delivers its value in one of three forms:

• env_var, an environment variable in the workload.
• file, a file the workload reads.
• egress, an outbound request header injected on the way out.

Secrets, secret versions and secret bindings are managed through the sylphx secrets commands.

#Limits

A plan bounds projects, members, databases, custom domains and concurrent runs; it does not bound environments. See Plans, usage and limits.