Named environments
A named environment is one you create yourself for something long-lived: staging, QA, a customer demo. It is based on an environment that already exists, deploys a branch of your choice on every push, and is built from a plan you review before anything is created.
Creating one
Open the environment selector in the project's navigation bar and choose New environment. Three answers come first:
| Field | What it is |
|---|---|
| Name | What the environment is called: staging, qa. The name becomes a slug of lowercase letters, digits and hyphens, starting with a letter, up to 30 characters. production and the pr-<number> shape are reserved. |
| Branch | The branch this environment deploys, on every push to it. It must exist in the repository. |
| Based on | The environment whose resources and configuration this one starts from: Production, or another named environment. |
Every resource keeps its component's name, so staging's copy of web is still web and references to database still read database; it is the environment that tells them apart. The slug leads the hostname of each service instead: staging-acme-a1b2c3.kuppit.app.
As soon as the source is chosen, Kuppit computes a plan from it and draws what the plan would make.
Deciding each component
The plan lists every component of the source environment, and asks what this environment gets for each. A web service is always either its own or absent. A database offers up to four choices:
| Choice | What you get | What it does to the bill |
|---|---|---|
| Create a new empty database | An isolated database of the same shape, with no data in it. | Adds usage |
| Clone the Production database | An isolated copy of its data at creation. Changes afterwards are independent. | Adds usage |
| Use the Production database | No new infrastructure. Both environments read and write the same data. | No added resource |
| Don't include | This environment has no database for this. | No added cost |
Kuppit marks one choice Recommended: for a database, cloning where the infrastructure can clone it, otherwise a new empty database. Sharing is never recommended. It is the cheap option, and it is offered as exactly that: choosing it shows an amber warning that both environments read and write the same database, and that changes from this environment can affect the source. Where a database cannot be cloned, the option is shown but cannot be chosen, with the reason.
Every choice carries the words for what it does to the bill and one sentence about what is billed on use. No figure is shown, because the fixed part of a usage-based bill is not the resource's price. Costs depend on compute, storage and network usage.
For a web service the choices are New service, deployed from this environment's branch with the source's configuration copied across, or Don't include. An environment needs at least one service to deploy, so a plan that includes none cannot be created.
Connections
Below the resources, the plan lists every connection the source has between the components you kept, and how it will be made in the new environment. A reference from a service to a database is re-created against whatever this environment provides for that database: the new copy, the clone, or the shared instance. A connection whose target is shared says so: it reads the source's database.
A connection to a component you left out is dropped, and the service's variable with it.
Variables and secrets
Configuration comes across as a copy, made once when the environment is created. Afterwards the two environments are independent.
- The source environment's own environment variables are copied to the new environment, where every service inherits them.
- Each new service receives a copy of its counterpart's variables, and its references are reconnected as above.
- Secrets are not copied unless you choose to. The plan lists every secret by name, with a checkbox per secret, all unchecked. Tick the ones this environment should carry across; set the rest on the new environment afterwards. No secret value ever appears on the page.
Secrets can only be copied to a service being created. A shared or absent service has nowhere to put them.
The summary and Create
Beside the plan, the summary keeps the whole decision in view: the name, branch and source, each resource with what was decided for it, how many connections and secrets come across, and the environment's overall impact on the bill. It updates as you change anything.
Choose Create environment. In one step Kuppit creates the environment, its resources, its hostnames and its variables, records the decision for every component, and then starts a deployment for each new service from the branch. The project opens on the new environment, and from then on every push to the branch deploys it.
If the source environment changed while you were deciding, for example a resource was added to it, Kuppit refuses the stale plan, refreshes it, and asks you to check it and create again.
What cannot be changed afterwards
A component's decision is made when the environment is created. There is no way to turn a shared database into a clone later, or to re-copy variables from the source. To change a decision, delete the environment and create it again. A component added to the project after the environment was created can be added to the environment on its own, as a new resource.
Limits
Each plan allows a number of named environments per project. Production and preview environments never count towards it. The number is provisional during the alpha, and Kuppit says what it is if you reach it.