Environments

A project can have several environments - for example production and staging. Each environment tracks its own branch, environment variables, domain, and container, so you can run the same codebase in parallel configurations without them stepping on each other.

Production and beyond

Every project gets a production environment automatically, tied to your default branch. On paid plans you can add more, each pointing at its own branch. When you push, orkestr matches the pushed branch to an environment and redeploys only that one - so a push to your staging branch never touches production.

production   ->  main
staging      ->  develop
preview-pr   ->  feature/checkout

Containers and URLs

• Production serves at {project}.orkestr.run.
• Non-production environments get their own distinct subdomain.
• Each environment runs its own isolated container with its own resource allocation, so load or a crash in one never affects another.

Environment variables

Set variables per environment from its page. They are encrypted at rest and injected into the container on the next deploy, so a variable change requires a redeploy to take effect. This is deliberate: it keeps a running container's configuration immutable and reproducible.

• Each environment has an independent set of variables - staging can point at a staging database while production points at the real one.
• Names starting with ORKESTR_ are reserved for the runtime.
• Add-on connection details are injected as variables automatically when you attach a database or cache.

Per-environment resources

Container CPU and memory come from your plan. On paid plans you can raise an environment's memory toward the plan's burst ceiling - useful when one environment (say production) needs more headroom than the others.

How other features use environments

• A Job runs against a specific environment's current image and inherits that environment's variables.
• Deployments are per environment - each environment has its own deploy history and rollback target.
• Add-ons attach at the project level and surface their connection variables to environments.

FAQ

What is the difference between an environment and a project?

A project is the repo and its overall configuration. An environment is one deployable instance of that project, tied to a branch, with its own variables and container.

Do environments share a database?

Only if you point them at the same one. Each environment has its own variables, so you decide whether staging and production share data or run against separate add-ons.

Why didn't my variable change take effect?

Variables are baked into the container at deploy time. Trigger a redeploy of that environment after changing them.