> ## Documentation Index
> Fetch the complete documentation index at: https://to11.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Environments
> Separate production from staging within a project using environments.
An environment is a named deployment target inside a project. Each project starts with two: **Production** and **Staging**. An environment doesn't hold its own copy of your configuration — providers, routing rules, and prompts are project-scoped. Instead, an environment is a set of pointers that decide *which version* of each resource is live in that environment.
That separation is the point. You change a routing rule or a prompt in staging, confirm it behaves, and then promote that exact version to production. Production keeps serving the version it was already pointed at until you move the pointer.
## What every project starts with
| Environment | Slug | Role |
| -------------- | --------- | ------------------------------------------------------------------------- |
| **Production** | `prod` | The default publish target and the environment the gateway falls back to. |
| **Staging** | `staging` | A pre-production environment for validating changes before promotion. |
Both are system environments, created automatically with the project. The `prod` and `staging` slugs are reserved — you can rename the display name, but you can't create new environments using those slugs.
You can add more environments — a `qa` or `canary` environment, for example — to fit how your team ships.
## What an environment owns
* **Version pointers** — which prompt version, which routing-rule release, and which provider activation serve traffic in that environment.
* **A promotion policy** — the rules that govern how changes move *into* it. See [Promotion policies](/docs/deploy/promotion-policies).
* **Display settings** — a name, a color, and an optional description.
* **Role flags** — whether it's the default publish target, the gateway fallback environment, or marked as production.
Providers, credentials, routes, and prompts themselves are shared across the project. The environment only selects which version of each is active.
## Managing environments
Environments live in the dashboard at **Project → Settings → Environments**, where you can add, edit, and reorder them. An environment is described by:
* **Name** — the display label (up to 64 characters).
* **Slug** — the stable identifier used in the API and in promotion rules. The slug is set when you create the environment and is immutable afterward, so pick it deliberately.
* **Description** — optional, up to 280 characters.
* **Color** — a label color to tell environments apart at a glance.
From the per-environment editor you can update the name, color, and description, reorder environments, and toggle three roles:
* **Default publish target** — where new versions publish unless you choose otherwise.
* **Production** — marks the environment as production for reporting and policy.
* **Gateway fallback** — the environment the gateway serves when a request doesn't resolve to a more specific one. Exactly one environment holds this at a time.
Editing environments requires the `project:manage_environments` permission. Changing the gateway fallback environment additionally requires `project:manage_default_environment`. See [Roles & permissions](/docs/platform/roles-and-permissions).
## Next steps
Control how changes move between environments.
Require sign-off before a change goes live.