Deployments

Production and preview deployments

Auto-deploy on push

Once your repository is connected, every push to your production branch starts a new build automatically. If another build for the same app is already in flight when a new push arrives, the older one is superseded — you're never stuck waiting behind a stale build, and a superseded build can't overwrite a newer one's result even if it finishes later.

Vorynza reports build and deploy status back to the commit on GitHub, so you'll see it directly on your pull request or commit.

Deployment status

Canceling a build

While a deployment is queued, building, or deploying, you can cancel it from the deployments list. This stops the build and marks it canceled — it won't affect production.

Rollback

Every successful deployment stays available. To roll back, open any previous Ready deployment and promote it back to production — your custom domains and platform subdomain immediately start serving that version again. For a Next.js app, this is instant: the previous deployment's function is already running, promotion just repoints traffic.

Manual redeploy

Trigger a new production build at any time from your app's overview page, without needing a new commit — useful after changing environment variables, which don't take effect until the next deployment.

Build cache

Vorynza caches your app's installed dependencies (node_modules, plus Next.js's incremental build directory) between deployments, so repeat builds skip most of the cold install work. The build log shows cache activity as [cache] lines: whether a cache was restored, skipped, or saved.

The cache is always safe: your package manager reconciles restored dependencies against your lockfile on every install, so an out-of-date cache only costs time, never correctness.

Redeploying without the cache

If a build fails on dependencies that install fine locally, redeploy without the cache: open the deployment's row menu and choose Redeploy without cache, or use Retry without cache on a failed deployment's page. The build starts cold, and a fresh cache is saved automatically once it succeeds — one clean build repairs the cache for every deployment after it.

Health checks

Websites with server code and backend services are verified after every deployment: Vorynza requests the app's URL and only marks the deployment Ready once it responds. A deployment whose process never answers is marked Failed with an explanation instead of silently serving errors.

Stuck deployments

If a deployment ever stalls (for example, the build environment is interrupted mid-run), Vorynza detects it automatically and marks it failed with a retry hint — a deployment never stays stuck in Building forever. Build logs for finished deployments are stored permanently, so you can always come back to an old deployment and read exactly what happened.