Environments and copies
An environment gives stack deployments a named context inside a project. Use names such as production, staging, or development to make their purpose clear. You create and select environments explicitly; creating one does not deploy services or provision a server.
Create an environment
- Select the workspace and project in the dashboard.
- Open Stacks, then select Create environment under Project environments. You can also create one inside a new stack editor without leaving its draft.
- Enter a name starting with a lowercase letter, with up to 40 lowercase letters, digits, or hyphens.
- Select Create environment and choose it when configuring the stack.
Environment names are unique inside the project. Creating the same name again returns the existing environment. Project write permission is required. Filter the Stacks list by environment to find its stacks.
What isolation means
| Item | Behavior |
|---|---|
| Configuration | Each stack has its own saved revisions |
| Private inputs | Encrypted per stack; saved values are not copied to another stack |
| Networking | Private service-name resolution is scoped to the stack on its pool |
| Named volumes | Scoped to stack identity, so copies receive separate storage |
| Server capacity | Shared if stacks use the same pool |
| Project access | Environments remain under the project’s existing permissions |
Two stacks in the same environment also have separate private stack networks. An environment name is not a separate server, a separate billing account, or a new permission boundary. Choose a different pool when your operational requirements call for separate server capacity.
Copy a stack to staging
- Open the source stack and select Copy to staging or another environment.
- Keep the source project selected. Copies are supported within the same project.
- Enter an unused stack name and select or create the target environment.
- Select a resource pool in that project. A new copy can target a different pool; the existing stack stays on its original pool.
- Inspect the copied services, images, repositories, branches, volume declarations, and runtime input references.
- Supply fresh values in Private inputs. Eligible template passwords are generated again if omitted; defaults can be resolved again. Required custom inputs must be supplied explicitly.
- Select Review deployment, inspect the target and changes, then select Deploy stack.
The editor proposes a name ending in -staging; change it when using another target or when the proposed name is already taken.
A copy contains configuration, not production data. Database contents, uploaded files, and saved secrets are not cloned. The new volumes start independently. The copy is not an automatic branch preview or data synchronization workflow.
Check external connections before deploying
Inspect values and references for payment providers, email delivery, webhooks, object storage, and other external services. Use test accounts, staging endpoints, and fresh credentials appropriate for the new environment. Update any public base URL expected by the application.
Service names usually remain the same in the copied manifest, so internal hostnames can remain familiar while resolving within the new stack’s network. External database URLs and third-party endpoints need explicit review; separation of stack storage does not isolate an external service you deliberately reconnect.
Copying a registry installation
A registry-based copy retains the originating release identity. New installation checks still apply, including release availability and tested pool architecture. Advanced configuration can mark the copy customized. Do not assume copying is a way to install a blocked or archived release; read release availability.
Plan data migration separately
If you need sample or restored data, use the application’s supported export/restore workflow after arranging an appropriate backup. Redact production personal data before using it in staging. Confirm image and database-version compatibility, storage paths, and credentials before restoring.
An existing stack cannot be moved by changing its Environment or Resource pool selector. A deliberate migration uses a new stack, a tested data transfer, application verification, and a planned traffic cutover. Keep the old installation and backup until the new one has been verified. See storage and backups and stack operations.