Environments

What an environment isolates#

Every project starts with production. Adding staging gives you a second, fully separate set of:

• apps, each with their own scaling and domains,
• environment variables and shared variables,
• databases, buckets, volumes and jobs.

Nothing is shared implicitly. A staging app cannot reach a production database, and neither can see the other’s variables.

Creating one#

In the console, open the project and add an environment. Environment slugs are up to 32 characters and unique within their project, so two projects can each have their own staging.

Promoting a release#

Promotion is the point of having environments. It takes a deploy that is already proven in one environment and releases that identical image into another — no rebuild, so there is no chance of picking up a different dependency version or a changed base image between test and production.

$ codaracloud deploys list my-api --env staging

$ codaracloud promote my-api \    --from-deploy <deploy-id> \    --from-env staging \    --to-env production

$ codaracloud deploys list my-api --env production

The target environment keeps everything that makes it itself — its own variables, its own database connections, its own domains and replica count. Only the image changes.

A workable branching setup#

Two common shapes, both of which Codara supports directly:

Branch per environment#

Point staging at the develop branch and production at main. Each environment builds its own branch on push. Simple, and the branch name tells you what is deployed where — but production builds code that has never been built before, so the two images are never bit-identical.

Build once, promote#

Point only staging at a branch. Nothing builds in production; releases arrive by promotion. This is the safer shape: what you tested is literally what ships. Turn off automatic deploys on the production app so it can only change by promotion.

$ codaracloud apps update my-api --env production --manual-deploys

Preview environments#

A project can opt in to creating an environment automatically for each pull request, so reviewers get a running copy of the change. Enable it per project:

$ codaracloud projects update website \    --client my-workspace \    --automatic-previews \    --preview-source production

The preview source is the persistent environment whose configuration is copied into each new preview. Previews are marked as such and are meant to be disposable.

Pausing an environment#

An environment can be paused as a unit. Apps and dedicated databases stop using compute, scheduled jobs are suspended, and new one-shot jobs wait until resume. Persistent volumes and shared database pools remain, so pausing reduces compute cost but does not make the environment free. Shared database tenants cannot stop their pooled server independently. Resuming restores the environment’s workloads. Pausing a project’s default production environment requires a second confirmation containing its exact slug.

Deleting an environment#

A persistent environment must be empty before it can be deleted: remove its apps, databases, jobs, and buckets first. A pull-request preview is different; its deletion performs retry-safe cleanup of the preview’s apps, databases and jobs after an explicit cascade confirmation. Buckets are never cascade-deleted because they may hold customer data, so they must be removed explicitly first. A project’s default environment cannot be deleted until a different environment is marked as default.