Test Pull Requests in Ephemeral Heroku Review Apps

The problem: your staging environment is a pull-request bottleneck

When a feature branch sits in GitHub, product managers, designers, and QA engineers often have to wait for a shared staging slot to open up. If staging is occupied by another branch, testing stalls. Worse, testing directly on production is risky, and running the full stack locally can be slow or inconsistent with the deployed environment.

The useful takeaway is that Heroku Review Apps can automatically provision a temporary, isolated application for every pull request. Review Apps use the parent pipeline's buildpacks and add-on configuration, so reviewers can test a live build without touching production or waiting on a shared environment.

What a Review App is and how it is created

A Review App is an ephemeral Heroku app generated from a pull request. "Ephemeral" means it exists for a limited time and is destroyed when the pull request is merged or closed. Heroku Pipelines connects a GitHub repository to a pipeline; when Review Apps are enabled, opening a pull request triggers a new app with a unique herokuapp.com URL.

Buildpacks are the scripts Heroku uses to compile and run your code. Add-ons are managed services such as Heroku Postgres or Heroku Redis. Review Apps inherit the pipeline's buildpacks and can provision add-ons, though availability depends on account verification and remaining add-on credits.

Enable Review Apps and configure app.json

In the Heroku Dashboard, open the pipeline connected to your GitHub repository and look for the Review Apps section. You can also verify from the command line. Run this in your local terminal with the Heroku CLI installed and logged in:

heroku pipelines:info 

Replace with your pipeline's name. You need membership in the team or app that owns the pipeline. This is a read-only check, so it does not change infrastructure. If Review Apps are enabled, the output includes a Review Apps section; if not, enable it in the Dashboard under the pipeline's settings.

To control what each Review App receives, add an app.json manifest to the repository root. This file defines add-ons, environment variables, and post-deploy scripts. Example:

{
  "addons": ["heroku-postgresql", "heroku-redis"],
  "env": {
    "NODE_ENV": { "value": "production" }
  },
  "scripts": {
    "postdeploy": "bundle exec rails db:migrate"
  }
}

Not every add-on supports automatic provisioning in Review Apps. Check the add-on's documentation before listing it in app.json, or the generated app may fail to start.

Worked example: pull request to teardown

1. Open a pull request in the GitHub repository connected to the pipeline.
2. Heroku builds the branch and provisions a Review App. The Dashboard and the pull request conversation show a unique URL such as pr-123-example-app.herokuapp.com.
3. Share that URL with QA, design, or product stakeholders. They can interact with the live build as they would with staging.
4. When the pull request is merged or closed, Heroku destroys the Review App automatically. Any data written to its local database or filesystem is lost.
5. If you need to tear one down manually before the pull request closes, run heroku apps:destroy --app from your terminal. This is state-changing and irreversible; confirm the app name first because there is no undo.

Trade-offs and limitations

• Cost: Review Apps consume dyno hours and add-on resources. Repositories with heavy pull-request traffic can increase the monthly bill.
• Ephemeral data: Because the app is destroyed after the pull request, do not rely on it for long-lived test data. Use an external database or storage service if results must persist.
• Add-on support: Not all add-ons are eligible for automatic Review App provisioning, and some require account verification.

Practical check before you roll out

Enable Review Apps on one low-traffic pipeline first. Open a pull request, confirm the app appears in the Dashboard with a working herokuapp.com URL, then merge or close the pull request and verify the app is destroyed. Monitor dyno-hour usage in the Heroku Dashboard for a few weeks before expanding to more repositories.