Deployment lifecycle

Each time you trigger a deploy, Velumi creates a new deployment record for that environment. The deployment moves through a series of statuses as it progresses.

Statuses

ready, failed, and superseded are terminal — the deployment will not change status after reaching one of these.

Cutover probe and authentication middleware

Before switching traffic to a new deployment, Velumi sends an unauthenticated request to the root path:

GET /?__templ_cutover_probe=<timestamp>-<random>
Cache-Control: no-cache
Pragma: no-cache

If your app uses Basic Auth, login redirects, or other middleware that restricts requests, make sure this probe receives HTTP 200 rather than an authentication challenge, redirect, or error. The query parameter is __templ_cutover_probe, with two leading underscores. Its value changes between requests; check for the parameter's presence, not a specific value.

Handle the probe before authentication challenges or redirects, using all three conditions:

• The request method is GET.
• The URL pathname is exactly /.
• The query string contains __templ_cutover_probe.

Return a fixed plain-text response such as ok, with Cache-Control: private, no-store, and end the request immediately. Do not skip authentication and continue into your application: the parameter is public, not a secret or proof that a request came from Velumi. Never return protected pages, assets, or API data through this exception.

Keep all other paths and methods protected, even when they include the same parameter. If required configuration is missing or invalid and the app cannot safely serve traffic, return an error rather than reporting readiness. A blocked probe can prevent deployment cutover even when the build succeeds.

What "current" means

Each environment has exactly one current deployment — the one with status ready that is actively serving traffic. When a new deployment reaches ready, the previous current deployment transitions to superseded.

Triggering a deployment

Go to Project → Environment → Deployments and trigger a new deployment. You can also restart a stopped environment or retry a failed deployment from the same view.

A deployment is also triggered automatically after a project is created.

One operation at a time

An environment runs one deployment or lifecycle operation at a time. What happens when you trigger a new action while one is already running depends on the action:

• Deploys are queued. Both a manual deploy and a push-triggered auto-deploy are held and run automatically once the current operation finishes. Triggering a deploy manually during an active operation shows a confirmation, then a "Deployment queued" message. (A push to a stopped environment is the one exception — it is ignored rather than queued.)
• Rollback and Stop take over immediately. These cancel the operation in progress and run right away — a rollback shouldn't have to wait behind a broken build, and a stop should bring the environment down now. You'll be asked to confirm, since the running operation is cancelled.

Detail page

Click any deployment in the list to open its detail page. It shows:

• Status and short deployment ID
• Source — branch, commit hash, and a link to GitHub (or "Archive upload" for zip sources)
• Triggered by label, and PR number if applicable
• Build duration
• Build log
• Error message for failed deployments
• A Preview button if the deployment has a preview URL