Docs Operate

Environments

An environment is a separate copy of a project’s services, with its own variables, domains, volumes and private network. Every project starts with production. Add others for staging, testing or previews, and let Dawnrose create one for each pull request.

Switch environments with the environment menu next to the project name at the top of the dashboard. On the canvas, E opens the same list in the command palette.

Create an environment

Open the project’s Settings and go to Environments, or choose New environment in the environment menu.

Enter a name, such as staging. Names are converted to lowercase with hyphens, up to 32 characters.
Choose Empty environment, or Duplicate an existing one.
Click Create environment.

From the CLI, dawn env new creates an environment and switches the current directory to it:

dawn env new staging --from production

Agents use create_environment with an optional from. The number of environments per project depends on your plan; see Scaling and plan limits.

What a copy contains

Copied	Not copied
Every service, with the same name, source, build and deploy settings Service and shared variables Volumes, with the same mount path and size, but empty TCP proxies, on a new public port Generated domains, as new hostnames The latest uploaded code of services deployed from files	Sealed variables Custom domains Data in volumes Deployments and logs

Variables that reference other services, such as ${{ Postgres.DATABASE_URL }}, resolve to the services of the new environment, so a copied app uses the copied database. Set sealed variables again in the new environment.

A copy is not deployed when it is created. Services with a repository or image show as never deployed in the pending changes banner; deploy them from there, with dawn deploy --all, or with the agent’s deploy_changes. Services deployed from uploaded files are not in the banner; deploy each of them with dawn deploy --service NAME, which builds the copied upload.

Deploying pending changes

Changes to a service’s settings, variables or volume, and to shared variables, are staged until the service deploys again. When any service in the environment has staged changes, the canvas shows a banner such as 2 services have changes. Details lists what changed for each service. Deploy (or Shift+D) deploys every changed service at once.

When only deploy settings or the volume changed, Dawnrose reuses the running image. Changes to the source, build settings or variables start a new build.

The same action is dawn deploy --all in the CLI and deploy_changes for agents.

Pull request environments

On the Hobby and Pro plans, Dawnrose creates a preview environment for each pull request in a GitHub repository that a production service deploys from.

When a pull request is opened or reopened, Dawnrose creates an environment named pr-<number> as a copy of production. Every service that deploys from a Git repository is set to the pull request’s branch, and every service with a source is deployed.
When you push to the pull request’s branch, auto-deploy redeploys the services that use that branch.
When the pull request is closed or merged, Dawnrose stops its containers and deletes the environment.

Pull requests from forks are not deployed. Pull request environments show a PR #<number> badge in the environment list. Like any copy, they get new generated domains and empty volumes, and they do not get sealed variables.

Pull request environments rely on the webhook Dawnrose adds to the repository when you create a service from it with GitHub connected. See Sources.

Delete an environment

In the project’s Settings → Environments, click the trash icon next to the environment and type its name to confirm. This removes every service, volume and domain in it. production cannot be renamed or deleted. Deleting an environment needs the admin role.

dawn env delete staging