Skip to content
Environments

Environments

Production, preview and named environments, what each one contains, and how they stay isolated from each other.

An environment is one complete instance of your application: its own resources, its own variables, its own hostnames, deploying its own branch. Every project has a Production environment, and the dashboard's environment selector, in the project's navigation bar, switches between all of them. On the project's Overview, which draws every environment at once, the selector reads All environments; choosing one brings that environment's box into the frame.

TypeHow it startsHow it endsDeploys
ProductionWith the project.With the project. It cannot be deleted on its own.The production branch.
PreviewAutomatically, when a pull request opens. Named PR #42.Automatically, when the pull request closes.The pull request's branch.
NamedBy you, from an existing environment, for staging, QA or anything long-lived.By you.A branch you choose.

Each is described on its own page: preview environments, named environments, and deleting an environment.

What every environment has

Whatever its type, an environment gets the full project view:

  • Overview draws the whole project — every environment as a box, its resources inside, the connections between them — with this environment's box brought into the frame, and says in one line which of the project's components it deliberately does not have.
  • Activity lists its deployments and events.
  • Variables holds the environment variables every service in it inherits.
  • Settings for what can be changed after creation.

A resource page opened from an environment stays in that environment's scope, so its siblings and its parent link are the right ones.

Components and instances

A project is made of components: the web service, the database database. An environment decides, for each component, what it has:

DecisionThe environment gets
Create newIts own instance of the component, empty.
ShareAnother environment's instance, used in place. No new infrastructure.
CloneIts own instance, seeded from a copy of another environment's data.
Don't includeNothing. The component is deliberately absent.

The decision is recorded even for Don't include, so an environment created without a worker stays distinguishable from one created before the worker existed. Which decisions are available depends on the component: a web service is always its own or absent, a database can be any of the four. The full table of options, with what each costs, is on named environments.

Isolation

Environments are isolated by default. A service references only resources beside it in the same environment, a variable set in one environment does not exist in another, and a preview never receives a database.

Sharing is the one decision that crosses the line. On the overview a shared database is drawn once, in the environment that owns it, and every service that reads it from another environment is joined to it by an edge that crosses into the owner's box — in amber when the owner is Production. The environment that shares it says so beneath its cards, and the database's page says in amber that writes from there change the owner's data. Kuppit does not copy or isolate it. If that is not what you want, clone instead.

Branches

Production deploys the project's production branch. A preview deploys its pull request's branch and is updated on every push to it. A named environment deploys the branch you gave it when you created it, on every push.

Environments do not promote into each other: there is no button that turns staging into production. Merging the branch is the promotion.

Was this page helpful?