Documentation / Build and deploy
Environments and previews
Production, staging, pull requests, and what a copy includes.
Production and staging
A project starts with production. Create another environment by copying an existing one, for example staging. You can select a branch for the new environment. Always check the environment selector before changing variables, inspecting logs, deploying, or restoring a backup.
What a copy includes
| Item | Result |
|---|---|
| Service and shared variables | Values are copied; references resolve within the new environment |
| Generated domains | New hostnames for the new environment |
| Volumes | New empty volumes at the same mount paths |
| Custom domains | Not copied |
| Database contents | Not copied |
Services with a repository or image are deployed as part of duplication, except imported services explicitly waiting for cutover. A service uploaded only through the CLI has no reusable repository source and needs another upload.
The service definition is shared across environments, while runtime instances and data are separate. Some service settings, including Network Permissions and enabling Deploy Watch, affect the service as a whole. Existing instances need the documented deployment steps to apply changed runtime settings.
External side effects
A copied literal DATABASE_URL, payment key, bot token, or email credential can still point to production. Use staging credentials and replace external URLs before deploying code that writes data or sends messages. Empty volumes do not prevent code from reaching an external production database.
Pull request previews
Enable pull request environments in the project's settings when GitHub is connected. A preview uses its own environment and generated address. Closing the pull request removes its preview resources. Preview volumes are temporary and are excluded from scheduled backups.