Preview deployments

Push a branch that is not your default branch and deploybase builds it, publishes it, and gives it a URL of its own. Production is untouched.

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

Branch feat/redesign on a project whose preview slug is my-blog becomes https://feat-redesign-my-blog.previews.deploybase.eu.

The URL is stable for the life of the branch: push again and the same address serves the new build, usually within seconds of the build finishing. There is one preview per branch, so a new deployment replaces the previous one rather than accumulating.

Previews carry X-Robots-Tag: noindex, nofollow, so search engines are asked to stay away. Whether anyone with the URL can open one, or only your team, is a setting: see who can open previews.

How a branch name becomes a hostname

A hostname cannot contain most of what a branch name can, so the name is normalised:

Rule	Example
Lowercased	Feature/Auth → feature-auth
/ and _ become -	feat/new_login → feat-new-login
Anything else non-alphanumeric is dropped	fix@bug#123 → fixbug123
Truncated to fit the 63-character limit	Long names are shortened, keeping the slug suffix

Two branches that normalise to the same string collide on one hostname. It is rare, and feat/nav alongside feat-nav is how it happens.

Changing the preview hostname

The preview slug is the Preview label under Branch previews → Preview rules → Preview address. It takes 3 to 63 characters: lowercase letters, digits and single hyphens, no hyphen at either end. It has to be unique across all of deploybase, because every team shares the previews.deploybase.eu namespace.

Changing it moves every current preview of that project to the new address immediately, with no rebuild. The old addresses stop working at once, with a 404 rather than a redirect, so update anything pointing at them:

• Bookmarks and links in review tickets
• CI scripts that construct or assert a preview URL
• README badges
• Webhook or OAuth callback URLs registered against a preview

The old slug stays reserved for your team for 30 days, so you can change your mind, and nobody else can take it in the meantime.

Renaming the project does not touch the preview slug, and neither does changing your production subdomain. They are three separate names.

Choosing which branches build previews

By default every non-default branch builds on push. Branch previews → Preview rules → Branches that build narrows that:

Mode	Effect
Every branch	Every push builds a preview. The default
No branches	No push builds a preview
Matching branches	A branch builds when it matches an include pattern and no exclude pattern

A pattern is an exact branch name, or one * wildcard used alone, at the start or at the end. The wildcard matches anything, / included.

Pattern	Matches
staging	staging and nothing else
release/*	release/2026-08, release/hotfix/db
*-preview	docs-preview, feat/nav-preview
*	Everything

Patterns with more than one *, or a * in the middle, are rejected. Excludes win: a branch matching both lists does not build.

Three things the policy never blocks:

• Your default branch. It always builds and always promotes, in every mode
• Merge and pull requests. Governed only by the separate “Build previews for merge requests” toggle
• Deploys you asked for, from the dashboard, the CLI, the API or MCP

Narrowing the set is worth doing on a busy repository: every preview build spends build minutes, and a long-lived branch nobody is reviewing is spending them for nobody.

Who can open previews

Each project decides who can open its branch previews. The setting is Who can open previews, under Branch previews → Preview rules, and it covers every branch preview of the project, including branches you push later.

Choice	What a visitor sees
Anyone with the link	The preview, with no sign-in
Your team (sign in with deploybase)	A sign-in page at app.deploybase.eu. Members of your team sign in with their deploybase account; nobody else gets in
Your team and people with the password	The same sign-in page, with a password field as well. Your team signs in as usual, and anyone else types the password you gave them

Previews stay noindex, nofollow whichever you choose. Owners and admins can change the setting. Members see it but cannot change it, and viewers see a note in its place. A change can take up to about 15 seconds to save.

In the dashboard, a private preview carries a lock with Team only or Team + password: in the list of previews, in the rules summary, and on the deployment page of a preview.

New projects start private: only your team can open their previews. Projects that existed before keep their setting, so their previews stay open to anyone with the link until you change it.

The password

A project has one password, and it opens every branch preview of that project, including the previews of branches you push later. You add it when you pick Your team and people with the password:

• Generate a password gives you four plain words joined by hyphens. It is shown once: copy it before you press Done. We keep only a hash of it, so nobody can show it to you again.
• Set my own takes at least 12 characters. Common passwords are refused.

Your team stays signed in for 8 hours and guests for 24 hours. After that they sign in again.

Action	What happens
Change password	Everyone who opened a preview is signed out. Guests need the new password; your team signs in again with deploybase
Remove password	Only your team can get in. Everyone is signed out, and you can add a new password at any time
Sign everyone out	Everyone signs in again, your team and guests alike. The password stays the same
Choosing another level	Moving away from Your team and people with the password removes the password and signs everyone out

After 100 wrong passwords in a row, password sign-in for that project’s previews pauses for 15 minutes and the team’s owners get an email. Your team can still sign in during the pause, and guests who are already in keep their access. If the attempts were not expected, change the password.

Right after you make previews private

When you save, deploybase clears the copies of your previews that were cached while they were public. The setting says Protected once that is confirmed. If it could not be confirmed, it says that some older public copies may still be served for a short while, with a Try again button.

What it does not cover

• Production stays public. Your production site and your custom domains are open to anyone, whatever you choose here.
• Share links are separate. A share link points at one specific deployment and has its own optional password and expiry, set per link. This setting does not apply to share links: anyone with the link, and its password if it has one, can open it. Use a share link to send one agreed version to someone outside your team.

Previews and production side by side

	Production	Preview
Built from	The default branch	Any other branch
URL	{subdomain}.sites.deploybase.eu, plus your custom domains	{branch}-{preview-slug}.previews.deploybase.eu
Environment variables	The production set, plus all, for builds and functions	The preview set, plus all, for builds only
Search engines	Indexed	noindex, nofollow
Access	Public	Anyone with the link, your team, or your team and people with the password
Lasts	Until another deployment is promoted	Until the branch is redeployed or the preview is deleted

Custom domains cannot point at a preview. The previews.deploybase.eu namespace is ours.

Promoting a preview

The deployment behind a preview is an ordinary deployment, so it can go straight to production without rebuilding: review it on the preview URL, then promote exactly that build. See roll back to a previous deployment, which is the same operation.

Preview deployments are kept on the same terms as every other deployment. See how long deployments are kept.