Deployment
Staging vs Production: A Release Process Small Teams Can Run
A minimal but effective flow for staging, production, and releases that doesn’t require a large DevOps team.
Small teams need a release process that catches issues before production without a lot of overhead. Staging plus a few rules is enough.
What staging is for
Staging is a copy of the app (and ideally data) that mirrors production so you can test changes in a realistic environment. Deploy the same branch (e.g. main) or the upcoming release branch to staging first. Run smoke tests or a quick manual check: login, key flows, and “did the thing we changed work?” Use staging to verify deployments and config (env vars, feature flags) before promoting to production. Staging doesn’t have to be perfect; it has to be good enough to catch obvious breakage.
Simple flow
Develop on feature branches; open PRs when ready. Preview (e.g. Vercel/Netlify preview per PR) for quick visual and functional check. Merge to main (or release branch). Deploy to staging automatically on merge (or trigger manually). Verify on staging: critical paths and the changes in the release. Promote to production (same artifact or a production deploy from the same commit). Monitor after release (errors, core flows). If something breaks in production, roll back (revert deploy or promote previous deployment) and fix forward.
Env and data
Staging should use staging APIs, staging DB, and staging keys—not production. Duplicate env vars in your host with “staging” values so a mistake in code or config doesn’t affect real users. Use anonymized or subset production data in staging if you can; otherwise seed data that’s close enough to reality. Refreshing staging from production (sanitized) periodically keeps it representative.
Who does what
Define who can deploy to staging vs production if you need a gate; many small teams let any dev deploy to staging and require a second pair of eyes or a lead for production. Document the steps (where to click, what to check) so anyone can run a release. Keep the process in a one-pager or runbook so it’s repeatable and new people can follow it.
Summary
Use staging to test the same build and config you’ll ship to production. Flow: merge → deploy to staging → verify → promote to production. Keep staging env and data separate from production. Document the steps and who can do what. That’s a release process small teams can run without big DevOps overhead.