Create a staging environment
By the end of this page the project has a staging environment deploying the develop branch, with its own copy of the web service and its own database, reachable on its own hostname. Production is untouched.
Before you begin
- A project with a Production environment that deploys.
- A
developbranch in the repository. Kuppit checks that the branch exists before creating anything. - Room on the plan for one more named environment. Production and previews never count against it.
Open New environment
In the project's navigation bar, open the environment selector and choose New environment.
Name it, and give it a branch
Enter staging as the Name. The hint beneath says hostnames start with staging-; the resources keep their names. Enter develop as the Branch. Leave Based on as Production.
Kuppit computes the plan from Production as soon as the source is chosen, and draws the environment it would make.
Decide the database
Under Resources, the web service offers New service, already chosen: staging gets its own deployment of develop, with Production's configuration copied across. That is right.
The database offers four choices. For staging, choose Clone the Production database where it is offered and recommended: an isolated copy of Production's data as of now, which makes staging behave like Production without touching it. If cloning is not available on this infrastructure, Create a new empty database is the recommended choice instead, and staging starts empty.
Do not choose Use the Production database for staging. It is the cheapest option and it is offered as that, but it means every write from staging changes Production's data; the amber warning says so when it is selected.
Check the connection
Under Connections, web → database reads Connected automatically: the reference ${{ database.DATABASE_URL }} is re-created against staging's own database. Nothing to do.
Choose which secrets come across
Under Environment variables, every non-secret variable is copied. Secrets are listed by name with an unchecked box each. Tick the ones staging should carry, such as a third-party API key that is safe to share between the two, and leave the rest; you set those on staging afterwards. No value appears on the page.
Create it
The summary beside the plan lists the name, the branch, the source, each resource with its decision, and Estimated impact: Adds usage, because a service and a database are being created. Choose Create environment.
Kuppit creates the environment, its resources and its hostname in one step, then starts a deployment of develop for the service. The project opens on staging; the service's hostname is staging-<project>-<id>.kuppit.app.
Afterwards
- Set the secrets you withheld on staging's service Variables tab, then Redeploy now.
- Push to
develop. Every push deploys staging's service, exactly as pushes to the production branch deploy Production. - Staging's variables live on its own Variables tab. Anything every service in staging should read goes there; a service's own variable of the same name wins.
- Merging
developinto the production branch is how staging's changes reach Production. There is no promote button; the branch is the promotion. - Deleting staging destroys its service and its database, with all of its data. Production's database is untouched, because staging had its own. See deleting an environment.
Named environments has the full account of every choice on the plan.