Heroku Review Apps: Instant PR Environments and the Cost Reality

Problem: How to Test a Pull Request in Isolation?

When a team pushes a new feature to a GitHub pull request, the usual workflow is to run unit tests locally, then manually spin up a staging environment to verify the change against the real stack. This process is slow, error‑prone, and requires the same credentials that production uses. The question many developers ask is: Can I get a fresh, disposable Heroku app that mirrors my PR branch and runs the same buildpack, add‑ons, and environment variables automatically?

Thesis: Heroku Review Apps Automate the Entire Pipeline

Heroku’s Review Apps feature answers that question by provisioning a brand‑new Heroku app for every pull request. The app is built from the PR branch, inherits the configuration defined in app.json, and is destroyed when the PR is closed or merged. This means you get a consistent, repeatable environment for visual QA, integration tests, and demo purposes—without manual intervention.

1️⃣ Setting Up Review Apps

To enable Review Apps you need two simple pieces of configuration:

1. Connect Heroku to GitHub. In the Heroku Dashboard, open the Deploy tab of your app, choose GitHub as the deployment method, and authorize Heroku to read your repositories. Once connected, toggle Enable Review Apps.
2. Define app.json in the repo root. This JSON manifest tells Heroku how to build the app, what add‑ons to provision, and which scripts to run after deployment.

After these steps, every new pull request will trigger a webhook that tells Heroku to create a new app, run the build, and expose a URL.

2️⃣ Example app.json

Below is a minimal, but realistic, app.json that you might find in a Rails or Node.js project. Replace the placeholders with your own values.

{
  "name": "myapp-review",
  "description": "Review App for PRs",
  "repository": "https://github.com/yourorg/yourrepo",
  "stack": "heroku-24",
  "buildpacks": [
    { "url": "heroku/ruby" }
  ],
  "addons": [
    "heroku-postgresql:hobby-dev"
  ],
  "env": {
    "RAILS_ENV": { "value": "test" },
    "SECRET_KEY_BASE": { "generator": "secret" }
  },
  "scripts": {
    "postdeploy": "bundle exec rake db:migrate && bundle exec rake db:seed"
  }
}

Key points:

• Stack must match the base Heroku stack you use in production.
• Each addon is provisioned per review app; the example creates a hobby PostgreSQL instance.
• The env section can generate secrets on deployment, keeping the repo free of sensitive data.
• Post‑deploy scripts run after the app is up, ensuring the database is ready.

3️⃣ Cost Reality and Dyno Hours

Heroku’s free tier for Review Apps was removed in 2023. Every running dyno now consumes billable dyno hours. A typical review app runs a single web dyno on the free or standard-1X type, but if you provision add‑ons like Postgres, each instance also consumes dyno hours.

Because review apps are created automatically, a busy team can easily generate dozens of running dynos during a sprint, leading to unexpected charges. Monitoring is essential:

• Navigate to Resources in the Heroku Dashboard to see active dynos.
• Enable Heroku Metrics to track usage per app.
• Set up a billing alert in the Billing section to warn when dyno‑hour usage exceeds a threshold.

Remember that database data is not persisted across review apps unless you use a shared add‑on or restore from a backup. This is fine for visual QA but not for integration tests that rely on production data.

4️⃣ Trade‑Offs and Limitations

Pros

• Zero manual setup—heroku handles build, deploy, and teardown.
• Consistent environment that matches production stack.
• Built‑in integration with GitHub PR lifecycle.

Cons

• Cost: every dyno and add‑on is billable; no free tier.
• Ephemeral data: databases are reset unless you back them up.
• Limited to standard dyno types; you cannot run GPU or high‑memory dynos in a review app.
• Concurrent PRs can overwhelm your account’s dyno quota.

Actionable Checklist

1. Connect Heroku to GitHub and enable Review Apps on the target app.
2. Add a validated app.json to the repo root.
3. Open a test pull request; verify the review app URL appears in the PR description.
4. Check the Resources tab to confirm dyno and add‑on creation.
5. Set up billing alerts to keep dyno‑hour usage in check.
6. Document the review app lifecycle in your team’s workflow guide.

By following this checklist you’ll have a reliable, repeatable environment for every PR—speeding up QA while keeping costs predictable.