How To Set Up a Staging Environment on Heroku in 3 Easy Steps

Summary

The guide explains how to add a Heroku staging environment so changes are tested in a near-identical, isolated replica before production. It uses a pipeline with production and staging apps, disables production automatic deployments, connects staging to GitHub, and enables automatic builds, with Review Apps offered for pull requests. The setup applies Twelve-Factor practices by separating config vars and databases, recommending migrations into a fresh Postgres database or warning that pg:copy overwrites staging data and can create compliance risks. After validation, slug promotion sends the exact compiled staging asset to production without recompiling, while numbered releases support rollback; database changes must still be reversed separately.

Takeaways

1. 1

   Heroku pipelines route GitHub changes through staging first, while production automatic deployments are disabled to prevent operational conflicts.

2. 2

   Staging should use separate config vars and a distinct database; migrations into a fresh Postgres database avoid copying sensitive production data.

3. 3

   Slug promotion deploys the exact artifact compiled in staging without recompilation, but rolling back a release does not reverse database schema changes or migrations.