Using Scalingo Review Apps to Test Pull Requests in a Live Environment

The problem: testing changes before they reach production

When a pull request opens, developers often want to see the code running in an environment that mirrors production. Running tests locally or in a CI container can miss runtime‑specific issues such as service discovery, external API behavior, or build‑pack quirks. Creating a full‑scale staging app for every PR is wasteful and slow to tear down.

Thesis: Scalingo Review Apps give you an isolated, production‑parity preview for each PR, automatically cleaned up when the PR closes

Review Apps are short‑lived containers built with the same buildpacks, Dockerfile, and config vars as your main app. Scalingo creates them when a PR is opened, gives them a unique sub‑domain, and destroys them when the PR is merged or closed, preventing orphaned resources.

Enabling Review Apps for an existing Scalingo app

1. Prerequisites: You need owner or collaborator rights on the Scalingo app and write access to the linked GitHub repository.
2. Link the repo (if not already done) via the Scalingo dashboard → "Code" tab → "Connect a GitHub repository".
3. Enable the add‑on: In the dashboard, open the "Add‑ons" section, find "Review Apps", and click "Enable". You can also do this with the CLI:

# Run in your local terminal, replace  with your Scalingo app identifier
scalingo --app  reviewapps enable

This command requires the Scalingo CLI (scalingo) installed and authenticated (scalingo login). No special flags are needed; the command returns a confirmation that the add‑on is active.

Worked example: from branch push to preview verification

Assume you have a Node.js app named blog-demo linked to github.com/yourorg/blog-demo. You want to test a feature branch feature/login‑ui.

1. Push the branch and open a PR:

   git checkout -b feature/login-ui
   # make changes, commit
   git push -u origin feature/login-ui
   # Open a pull request on GitHub (UI or CLI)
   

2. Scalingo creates the Review App: Within a minute, Scalingo detects the PR, builds the slug using the same buildpack (or Dockerfile) as the main app, and provisions a container. You will see a comment on the PR with a URL similar to: https://blog-demo-123.scalingo.io where 123 is the PR number.
3. Verify parity:
   • Open the URL in a browser; the running code should reflect your branch’s changes.
   • Check environment variables via the CLI:

     scalingo --app blog-demo-123 env | grep BUILDPACK_SCALINGO
     

     You should see the same value as in the main app (e.g., nodejs).
   • Confirm the dyno formation matches your Scalingo.yml (or default web=1).

     scalingo --app blog-demo-123 ps
     

4. Close or merge the PR: Once feedback is complete, merge or close the PR on GitHub. Scalingo automatically tears down the Review App. You can verify deletion:

   scalingo --app blog-demo reviewapps list
   # Should return an empty list or not show the PR‑specific app
   scalingo info --app blog-demo-123 2>&1 | grep "not found"
   

   The dyno hours for blog-demo-123 stop accruing immediately.

Trade‑offs and limitations

• Resource consumption: Each Review App consumes dyno hours and storage proportional to its uptime. High‑frequency PR workflows (e.g., dozens of PRs per day) can increase your bill noticeably. Monitor usage via the dashboard’s "Consumption" tab or the CLI:

  scalingo --app  reviewapps usage
  

• Data persistence: Any file uploads, database writes, or cache changes are lost when the Review App is destroyed. If your tests need persistent state, you must rebuild it (e.g., seed a database) or use external services that survive outside the container.
• Impact on neighbours: Because Review Apps share the same underlying nodes as production apps, aggressive load testing in a preview can affect co‑located containers. Keep load tests modest or use a dedicated performance‑testing environment.

Actionable closing

To get the most out of Review Apps while avoiding surprises:

1. Set a default lifetime limit (e.g., auto‑destroy after 1 hour) via the dashboard if your PRs often stay open long.
2. Add a step in your CI pipeline that posts the Review App URL to the PR comment (Scalingo already does this, but you can augment with additional metadata).
3. Review your monthly dyno usage in the Scalingo console; if you see a steady increase correlated with PR volume, consider consolidating feature branches or using a shared preview environment for low‑risk changes.
4. Document the limitation that Review App data is ephemeral; update your testing checklist to include any required data seeding steps.

By following the steps above, you can confidently use Scalingo Review Apps to catch runtime‑specific issues early, keep your production environment stable, and maintain visibility into the cost of ephemeral previews.