A team staging workflow

managed.dev gives every plan git-style branch environments, which means a team can run a real review-and-release workflow instead of editing production through wp-admin. This guide lays out the recommended shape: short-lived feature branches get preview environments for review, a long-lived staging environment is where QA signs off, and promotion to production is a deliberate, snapshot-protected step.

The shape

branch → environment mapping

main            → production   (default branch)
staging         → staging      (long-lived, QA)
feature/*       → preview      (ephemeral, per-branch)

This mapping is configured once with branch routes: the default branch deploys to production, a staging branch is routed to the shared staging environment, and everything else becomes a disposable preview.

Staging is a clone, not a snowflake

Both staging and previews are clones of production — their own database and files, seeded from production. Bugs you only catch on identical, production-shaped data are the whole point of having them.

Step 1 — Feature branch → preview

Each developer works on a feature/* branch and pushes it to managed.dev, which provisions an isolated preview automatically.

Push a feature branch

git push managed feature/checkout-redesign

Reviewers open the preview URL, leave comments on the PR, and QA does a first pass on production-shaped data. Nothing here can touch production. To make this fully hands-off — a preview per PR with the URL posted back automatically — wire it into CI with the preview-environment-per-PR guide.

Step 2 — Merge to the shared staging environment

Once a feature is reviewed, merge it into the staging branch and push. That deploys the combined work to the shared staging environment where the team runs integration QA against everything queued for the next release.

Promote work into staging

git checkout staging
git merge feature/checkout-redesign
git push managed staging

The Environments tab in app.managed.dev showing the production environment plus a long-lived “staging” environment and two ephemeral “feature/*” preview environments, each with a status badge.

Staging is long-lived, so it’s the right place for cross-cutting QA: full regression passes, third-party integration checks, and content rehearsals. Use observability on the staging environment to catch errors and latency regressions before they’re anywhere near production.

Step 3 — Snapshot, then promote to production

When staging is signed off, promote to production. Always take a snapshot of production first — it’s your instant rollback point if anything looks wrong after the cut.

1. Capture a point-in-time snapshot of production (DB + files).

2. Run your QA gate against staging one last time — error-free traces, green checks, sign-off recorded.

3. Promote: merge staging into your default branch and push, or promote the reviewed environment from the dashboard.

   Promote to production

   git checkout main
   git merge staging
   git push managed main

4. Watch production requests and security blocks for the first few minutes. If something’s off, roll back to the snapshot in a click.

Promotion changes production

Promoting deploys to the live site. The pre-promotion snapshot is what makes this safe — never skip it. Rollback restores both database and files from that snapshot.

How roles fit

Map your team’s responsibilities onto managed.dev’s roles so the workflow has the right guardrails:

Role	Typical use in this workflow
owner / admin	Configure branch routes, manage the team, approve production promotion.
site_manager	Push branches, deploy to staging, run snapshots, promote.
observer	Review previews and read observability — no deploy or destructive actions.
billing	Plan and invoices only; not part of the release path.

A common setup: developers and release leads are site_manager, stakeholders and clients reviewing previews are observer, and only owner/admin configure the routes and own production promotion.

Tip

Group related sites into a project so roles, audit, and plan/usage are scoped together — handy when a team runs several sites on the same workflow.

Next steps

Branch routesMap main, staging, and feature/* to the right environments.

Promote & roll backPromote a reviewed environment and roll back from a snapshot.

Teams & rolesAssign owner, admin, site_manager, observer, and billing.

A preview per pull requestAutomate step 1 so every PR gets a live preview.