Preview Deployments

Preview deployments provide automatic, public URLs for every non-default branch. When you deploy from a branch other than the project’s default branch, deploybase creates or updates a preview at a predictable URL.

URL Pattern

https://{branch}-{slug}.previews.deploybase.eu

Example: Branch feat/redesign on project my-blog → https://feat-redesign-my-blog.previews.deploybase.eu

Branch Name Sanitization

Branch names are sanitized for use as DNS subdomains:

Rule	Example
Lowercased	Feature/Auth → feature-auth
/ and _ replaced with -	feat/new_login → feat-new-login
Non-alphanumeric (except -) removed	fix@bug#123 → fixbug123
Truncated to fit 63-char subdomain limit	Long names are shortened to include the slug suffix

How Previews Work

1. A deployment is triggered from a non-default branch
2. Build runs normally (same process as production builds)
3. On success, deploybase creates or updates an edge rule on the previews pull zone
4. The preview_deployments table is upserted: (project_id, branch) → deployment_id
5. The preview URL is immediately accessible

One active preview per branch per project. A new deployment to the same branch replaces the previous preview.

Controlling Which Branches Build Previews

By default every non-default branch builds a preview on push. Project settings → Git repository lets you narrow that, in three modes:

Mode	Effect on branches other than the default
All branches (default)	Every push builds a preview
None	No push builds a preview
Custom patterns	A branch builds only if it matches an include pattern and no exclude pattern

Pattern Grammar

A pattern is either an exact branch name or a single * wildcard, used alone, at the start, or at the end. The wildcard matches any characters, / included.

Pattern	Matches
staging	The branch staging only
release/*	release/2026-08, release/hotfix/db
*-preview	docs-preview, feat/nav-preview
*	Any branch

Patterns with more than one *, or a * in the middle, are rejected.

Excludes are evaluated first. A branch matching both lists does not build.

What the Policy Never Blocks

• The default branch. Pushes to the project’s production branch always build and auto-promote, in every mode.
• Merge and pull requests. These are governed solely by the separate “Build previews for merge requests” toggle, never by the branch patterns.
• Manual and API deploys. Deploys you trigger from the dashboard, the API, or the MCP server always run.

Preview vs Production

Aspect	Production	Preview
Trigger	Default branch deploy	Non-default branch deploy
URL	{slug}.sites.deploybase.eu or custom domain	{branch}-{slug}.previews.deploybase.eu
CDN	Direct (edge rules on tenant pull zone)	Direct (edge rules on previews pull zone)
Access	Public	Public
Persistence	Until another deployment is promoted	Until branch is redeployed or preview deleted

Promoting a Preview to Production

Any deployed deployment — including one backing a preview — can be promoted to production instantly. See Rollbacks for the promotion API and details.

Limitations

• Preview URLs are always public. For password-protected sharing, use Share Links.
• Wildcard DNS (*.previews.deploybase.eu) is managed by deploybase — no custom domains on previews.
• Preview deployments follow the same artifact retention rules as all deployments.