Staging
STAY-jing
A pre-production environment that mirrors production for testing before release.
Staging is an environment that mirrors production as closely as possible, used for final testing before code is released to users. It has the same infrastructure, configuration, and (ideally) realistic data. If code works in staging, it should work in production.
The gap between staging and production is where bugs hide. When staging uses a different database, different network configuration, or different data volume, it creates false confidence. The best staging environments are production clones with anonymized data.
Staging is also where non-engineering teams preview changes. Product managers verify features work as specified. QA teams run manual test scenarios. Designers check that the UI matches their mocks. Staging is the last chance to catch problems before users see them.
Examples
A feature is tested before release.
The deployment pipeline pushes the new checkout flow to staging. The QA team tests ten purchase scenarios with different payment methods, currencies, and error conditions. They find one edge case where the discount code fails on annual plans. The bug is fixed before production deployment.
A staging environment diverges from production.
Staging uses a small database with 1,000 test records. Production has 10 million. A new search query works fine in staging but times out in production because the query does not use an index that only matters at scale. The team adds production-scale data to staging.
A product manager previews a launch.
The PM reviews the new pricing page on staging, checking copy, layout, and pricing tier accuracy. They find that the Enterprise tier description is wrong. The developer fixes it and redeploys to staging. The PM approves it for production release.
In practice
Read more on the blog
Frequently asked questions
How similar should staging be to production?
As similar as possible. Same infrastructure, same configuration, same database engine, same network setup. The only differences should be scale (staging can be smaller) and data (staging should use anonymized production data, not fake data). Every difference is a potential source of bugs.
Do all teams need a staging environment?
Not always. Teams with strong CI/CD, comprehensive test suites, and feature flags can sometimes deploy directly to production with canary releases. But most teams benefit from staging as a safety net, especially when non-engineers need to preview changes.
Related terms
The live environment where real users interact with the application.
The process of releasing code to servers where users can access it.
Continuous integration and continuous deployment: automating code testing and delivery to production.
Quality assurance: the practice of testing software to find bugs before users do.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.