Environments

Environments let one app model serve different runtime targets. Use them to keep production behavior separate from preview and validation work.

When to use environments

Environment useExample
ProductionReal users, real external integrations, production webhooks, live agents.
PreviewBuilder validation, stakeholder review, custom page preview, sample data.
TestAutomated tests, migration rehearsals, fixture import, contract smoke tests.

Use environment names consistently in publish notes, runtime smoke tests, and agent handoffs.

Runtime behavior

Runtime requests resolve an environment before executing commands or reading projections. The selected environment determines the published config, projections, policies, credentials, adapters, and operational behavior used by the request.

Agent behavior

For builder agents, include the target environment in the prompt whenever publishing or validating runtime behavior. For runtime agents, make sure the MCP endpoint and service token target the intended app and environment.

Documentation rule

Any guide that instructs a user to publish, rebuild projections, import events, trigger policies, or call external adapters should name the target environment explicitly.