Projects and deployments

Preview and production

Every deployment gets its own URL; production follows the production branch, and you can promote, roll back or redeploy at any time.

Hostnames

Every deployment is served at its own hostname, and the project has one more for whatever is production:

<project>-<id>-<org>.deployments.dev.gov.vin   one deployment (id: the last 8 characters of its deployment id)
<project>-<org>.deployments.dev.gov.vin        production

Hostnames are a single DNS label of lowercase letters, numbers and dashes, cut at 63 characters. Custom domains always point at production.

Preview and production deployments

	Production	Preview
Built from	the production branch	any other branch
Environment variables	targeted at Production	targeted at Preview
When ready	becomes production	keeps its own hostname only
Crons	run (see Crons)	recorded, run only if promoted

When a production deployment becomes ready it takes over the production hostname, every custom domain and the project's crons in one switch. If two production builds finish close together, the one that finishes last is production.

Statuses

Status
`queued`	Created; the build is starting.
`building`	Installing and building.
`deploying`	Creating the server function and route.
`ready`	Serving at its hostname.
`error`	The build or publishing failed.
`canceled`	The build was stopped.
`expired`	No longer served; its server function and route were removed.
`skipped`	The push didn't change anything this project builds from; the previous deployment keeps serving. See Skipped pushes.

Promote, roll back, redeploy

Open a deployment's ⋯ menu in Cloud (needs deployments:write). The project's production card also has Instant rollback, which lists earlier ready production deployments to switch back to.

Promote to production makes a ready preview production immediately. Nothing is rebuilt: the production hostname, every custom domain and the crons switch to that deployment's build. A promoted preview keeps the preview environment variables it was built with.

Roll back to this deployment appears on earlier production deployments and works the same way. The next push to the production branch deploys over it.

Redeploy builds the same commit again as a new deployment with the same target, using the current environment variables and linked storage. A redeployed production deployment becomes production when it's ready. In-progress deployments can't be redeployed, and the project needs a linked repository.

Promoting and rolling back need the deployment's server function to still exist; expired deployments can only be redeployed.

Expiry

A daily cleanup removes the server function and route of:

preview deployments ready for more than 14 days, and
production deployments other than the current one and the two most recent others.

Their records stay, marked expired. Redeploy one to bring it back. The current production deployment never expires.

Planned

Promote a preview with production environment variables. Coming soon
After a rollback, hold automatic promotion of new production builds until you promote again. Coming soon