Using Scalingo Review Apps to Test Pull Requests in Isolation

The problem: testing changes without interfering with shared services

When a team works on multiple feature branches, developers often need to run the application against a real database or cache to verify behavior. Spinning up a separate staging environment for every branch is costly and error‑prone, while sharing a single staging service leads to data collisions and flaky tests.

How Scalingo Review Apps address the problem

Scalingo’s Review Apps feature automatically provisions an isolated containerized app for each branch that matches a pattern you define (commonly /* to cover all branches). The new app uses the same buildpacks, environment variables, and addon definitions as your production app, but runs under a unique subdomain such as myapp‑feature‑login.scalingo.io. Because each review app gets its own instances of declared addons (e.g., a PostgreSQL database or Redis cache), you can test against clean data without affecting other environments.

The lifecycle is tied to your Git host: when a pull request is opened, Scalingo receives a webhook, creates the review app, and posts the preview URL as a comment (or makes it available in the dashboard). When the PR is closed or merged, another webhook triggers teardown, freeing the resources.

Worked example: enabling Review Apps for a Node.js service

Assume you have an existing Scalingo app named blog-api linked to a GitHub repository. You want a preview for every branch.

1. Define the review‑app pattern in the Scalingo dashboard → App → Review Apps → set Branch pattern to /* and save.
2. Ensure your scalingo.yml (or Scalingo.json) lists the addons you need, for example:

   addons:
     - postgresql:standard
     - redis:stable
   

3. Push a new branch:

   git checkout -b feature/new‑endpoint
   # make a change
   git commit -am "Add health endpoint"
   git push -u origin feature/new‑endpoint
   

4. Within a few minutes, Scalingo will create a review app. In the dashboard you’ll see an entry like blog-api-feature-new-endpoint under the Review Apps tab, with a URL such as https://blog-api-feature-new-endpoint.scalingo.io.
5. Verify the environment and addons via the CLI (you need the Scalingo CLI installed and authenticated):

   # Replace  with the exact name shown in the dashboard
   scalingo --app blog-api-feature-new-endpoint env
   scalingo --app blog-api-feature-new-endpoint run "psql \$DATABASE_URL -c 'SELECT version();'"
   

6. The first command lists the inherited environment variables (e.g., DATABASE_URL, REDIS_URL). The second runs a simple PostgreSQL query to confirm the addon is reachable.
7. When you merge or close the pull request, Scalingo receives the corresponding webhook and marks the review app as Deleted. The associated Postgres and Redis instances are removed at the same time.

Trade‑offs and limitations to consider

While Review Apps give rapid feedback, they consume the same compute and memory quota as regular apps. If your plan allows, for example, 2 GB of RAM total and you run five concurrent review apps each using 512 MiB, you’ll hit the limit and either see throttling or incur over‑age charges. Monitor usage in the Resources view of the dashboard or via scalingo apps:stats.

Data stored in addons is **ephemeral**: any rows written to the review‑app PostgreSQL database disappear when the app is torn down. This is ideal for stateless testing but unsuitable for scenarios where you need to preserve data across PR cycles.

The automatic teardown relies on webhook delivery. If GitHub or GitLab experiences delays, or if your Scalingo app’s webhook endpoint fails, a review app may linger beyond the intended lifetime. Scalingo also applies an inactivity timeout (default 24 hours) after which idle review apps are suspended, but you should still periodically check the Review Apps list and manually delete stale entries via the dashboard or scalingo apps:destroy .

Actionable closing

To adopt Review Apps safely:

• Start with a conservative branch pattern (e.g., only feature/*) to limit the number of concurrent previews.
• Set resource alerts in your Scalingo account so you’re notified when RAM or container counts approach 80 % of your plan.
• Document the ephemeral nature of addon data in your team’s contribution guide; encourage developers to seed any required test data within the application startup scripts.
• Schedule a weekly cleanup task (a simple cron that runs scalingo apps:list --review and removes any app older than 48 hours) to catch any webhook‑related leftovers.

By following these steps you get per‑pull‑request preview environments that mirror production, while keeping an eye on the costs and cleanup responsibilities that come with on‑demand isolation.