Environments
What an environment is
An environment is a lane that cuts across Introspection: development, staging, or production. It isn’t a separate copy of the platform; it’s a dimension that other resources are scoped to or pointed at, so that work in one lane never bleeds into another.
The lanes give you a clean separation between traffic you’re testing with and traffic that’s serving real users.
How environments cut across the platform
A handful of resources are environment-aware, and together they keep the lanes isolated end to end:
| Resource | Relationship to environments |
|---|---|
| Runtimes | A runtime serves one or more specific environments; pointing an environment at a runtime activates that version for the lane. |
| API keys | Each API key is scoped to exactly one environment, so a staging key can’t drive production traffic. |
| Experiments | An experiment runs within a single environment; arms are compared on one lane’s traffic, never across lanes. |
Because each of these is bound to a lane, “test vs production” is enforced structurally rather than by convention. A staging key sends work to the runtime serving staging; an experiment on production only ever splits production traffic.
Promotion is moving an environment from one runtime version to another. The lane stays put; the version it points at changes, like a git ref moving between commits.
Setting an environment on a runtime
The two live lanes are managed differently. A runtime’s staging assignment is set directly: you point staging at a version to try it out. production is moved through a deploy, so promoting a version to production is a tracked step rather than an in-place edit. This keeps “what’s live” auditable while leaving staging fast to iterate on.
Related
- Runtimes: versions that serve specific environment lanes.
- Experiments: A/B tests scoped to a single environment.
- Projects: where API keys (each scoped to one environment) live.
- Core Concepts: how environments fit the rest of the model.