Skip to content
deploybase

Deployments

A deployment is an immutable snapshot of built static files produced by a single build. Once created, a deployment is never modified — it has a permanent CDN URL.

Deployment Lifecycle

Section titled “Deployment Lifecycle”
Deploy triggered (API call or git push)
    ↓
pending → queued → building → deployed
                                  ↓
                         (or) → failed / cancelled
Status Description
pending Deployment created, waiting for build slot
queued Build job submitted to Kubernetes
building Build in progress (install dependencies, run build command, upload artifacts)
deployed Build succeeded, artifacts uploaded to CDN, deployment is accessible
failed Build failed — check build logs for errors
cancelled Cancelled by user before build completed

Build Process

Section titled “Build Process”

Each build runs in an isolated Kubernetes Job: clone repo, install dependencies, run build command, upload artifacts to CDN, configure edge rules, and send notifications. See Build System for full details on isolation, resource limits, and Docker images.

SPA Fallback and Custom 404 Pages

Section titled “SPA Fallback and Custom 404 Pages”

After a build finishes, deploybase inspects the output to decide what to serve when a request path has no matching file. There is nothing to configure. It is detected per deployment, so changing the files in a later build changes the behavior from that deployment onwards.

In your build output Served for an unmatched path
200.html 200.html, with status 200
A _redirects file containing exactly /* /index.html 200 index.html, with status 200
404.html 404.html, with status 200 (a soft 404)
None of the above A plain 404 from the CDN

The edge rewrites the request to the fallback file and fetches it, so the response carries that file’s own status: 200. A 404.html served this way is a soft 404. Only the last row, where no fallback file exists, returns a real 404.

If a deployment has both an SPA fallback and a 404.html, the SPA fallback wins. This matches Netlify’s behavior: a catch-all rewrite hands routing to your app, and your app decides what a missing route looks like.

All of this applies to production URLs, branch preview URLs, and custom domains alike.

Other _redirects rule types, including 301 and 302 redirects, arbitrary rewrites, and force rules, are read and stored with the deployment but are not yet applied at the edge.

For framework-specific setup, see the SvelteKit guide.

Auto-Promotion

Section titled “Auto-Promotion”

When a deployment builds from the project’s default branch (usually main), it auto-promotes to production:

  • The project’s live_deployment_id is updated
  • The CDN edge rule is rewritten to serve the new deployment
  • CDN cache is purged

Non-default branch deployments create or update a preview deployment instead.

Promotion and Rollback

Section titled “Promotion and Rollback”

Promotion and rollback are the same operation: pointing production at a different deployment.

Terminal window
curl -X POST https://api.deploybase.eu/api/v1/projects/PROJECT_ID/promote \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"deployment_id": "DEPLOYMENT_ID"}'

This is instant — no rebuild occurs. Only deployments with status=deployed can be promoted. See Rollbacks for details.

Artifact Retention

Section titled “Artifact Retention”

Deployments are retained using a union rule (whichever keeps more):

  • Last 10 deployments per project
  • All deployments less than 30 days old

Artifacts for expired deployments are garbage-collected from CDN storage.

Build Logs

Section titled “Build Logs”

Build logs are available for deployments that have started building (building, deployed, or failed):

Terminal window
curl https://api.deploybase.eu/api/v1/deployments/DEPLOYMENT_ID/logs \
  -H "Authorization: Bearer $TOKEN"

For failed builds, errors typically appear near the end of the log.

Section titled “Related Concepts”