Definition: Environment isolation
Environment isolation is the separation between a project’s targets — default (production), preview targets, and agent-<id> environments — each instantiating the same stack.json with its own data, routes, and keys, so work in one cannot touch another.
Isolation by instantiation
An environment is not a folder inside production; it is the stack declared again under another target. Its tables start from its seed files, its buckets hold its own objects, its gateway routes serve its own URLs, and its API keys are minted in it. A destructive experiment in a preview cannot reach sideways into production rows because there is no shared store to reach into.
Guardrails at the borders
The CLI enforces the borders mechanically: a stack can pin space_id so a deploy fails if aimed at the wrong environment; deploying an agent/
Frequently asked questions
No. Each target has its own tables, buckets, and keys, seeded from the repository’s seed files. Sharing with production is impossible by accident; it would have to be built deliberately, in the open.
A stack can pin space_id, and deploy then fails against any other environment. Agent branches additionally warn when deployed outside their matching agent environment.
As many targets as the team finds useful — previews per branch, a staging target, agent-<id> environments per sandbox. Each live environment carries its own (usually small) storage meter, which is the honest incentive to close them.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.