Branch routes

Branch routes decide what happens when you push a branch. Each route matches a branch (or a glob of branches) and points it at a deploy target. They’re how you say “main is production, staging is the staging environment, everything else is a preview, and these branches deploy nothing.”

The four targets

Target	What a matching push does
live	Builds and deploys production — the live site.
staging	Builds and deploys the singleton staging environment.
preview	Provisions a per-branch preview environment, seeded from production.
ignore	Builds and deploys nothing. The push is accepted but no deploy runs.

live and staging are singletons — there’s exactly one of each per site. preview is per-branch: every branch that matches gets its own preview environment. ignore is for branches you don’t want to deploy at all, like long-lived integration branches or bot branches.

The default behavior

Out of the box, a site has a sensible default set of routes, so you can deploy without configuring anything:

• your default branch (main) → live
• a branch literally named staging → staging
• everything else → preview

That default is what makes git push managed feature/x “just work” as a preview. You override it when you want a different layout — for example routing release/* to staging, or sending dependabot/* to ignore.

Configure routes

Branch routes live on the site’s Deploys settings. Each rule is a branch pattern plus a target, evaluated top to bottom — the first match wins, so put specific patterns above the catch-all.

1. Open the site’s Deploys → Branch routes settings.
2. Add a rule: a branch pattern (exact name or glob) and a target.
3. Order rules so specific patterns sit above broader ones.
4. Save. The next push to each branch follows its route.

The Branch routes panel in the app.managed.dev dashboard for the acme-store site, showing an ordered list of rules: main → live, release/* → staging, dependabot/* → ignore, and a final * → preview catch-all.

Branch matching

Patterns support globs, matched against the full branch name:

Pattern	Matches	Doesn’t match
main	main	main-fix
release/*	release/1.4, release/hotfix	release/1.4/rc
feature/**	feature/checkout, feature/cart/coupon	featured
*	every branch (use as the last rule)	—

A single * (or **) at the bottom is the catch-all. If a branch matches no rule, the push is treated as ignore.

Worked examples

A common setup for a team shipping from pull requests:

Pattern	Target	Why
main	live	production deploys on merge to main
staging	staging	a stable pre-prod env to promote into
dependabot/*	ignore	don’t spin up previews for dependency bumps
*	preview	every other branch gets a reviewable preview

The prod-first guard

Production must exist first

Preview and staging environments are clones of production — they seed their database and files from it. So a branch can only deploy to preview or staging once production has been provisioned at least once. If you route a branch to preview before your first production deploy, the build is accepted but the clone has no source. Deploy your default branch to live first, then previews and staging have something to clone from.

Next steps

Connect git & deployAdd the managed.dev remote and trigger your first deploy.

Branch environmentsThe model behind routes — tiers, isolation, and per-environment config.