Serverless App Services 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 Serverless App Service has one more for whatever is production:
<project>-<id>-<org>.cactivecloud.com one deployment (id: the last 8 characters of its deployment id)
<project>-<org>.cactivecloud.com productionHostnames 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 Serverless App Service'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 Serverless App Service 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 Serverless App Service'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. Its server function switches to the Production environment variables first; values the build inlined (such as NEXT_PUBLIC_*) keep their preview values, so redeploy to production when those differ. Clear Use production environment variables to keep the preview's. Static previews are promoted as built.
Roll back to this deployment appears on earlier production deployments and works the same way. Production then stays on it: new builds of the production branch become ready at their own hostname but don't take over production until you promote one, or turn automatic promotion back on from the notice on the Serverless App Service's overview.
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 Serverless App Service 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, and their build outputs (artifacts, static files and Next.js cache) are deleted. Redeploy one to bring it back. The current production deployment never expires.
Deployment protection
By default every hostname is public. In the Serverless App Service's Settings → Deployment Protection, Require sign-in on deployment URLs makes each deployment's own hostname (previews included) open only for signed-in members of the organization with deployments:read; the production hostname and custom domains stay public. Visitors without a session are sent to sign in and come back to the page they asked for; a session lasts 12 hours per deployment hostname. Other methods than GET and HEAD without a session get 401.
For automation (tests, monitors, webhooks), create a protection bypass secret on the same page and send it as the x-si-protection-bypass header or query parameter. It's shown once; regenerate or revoke it at any time.