Enabling Scalingo Review Apps: Decision Guide and Practical Setup

Decision and Constraints

Review Apps give each pull request its own short‑lived Scalingo environment, eliminating the staging bottleneck where multiple features fight for a single shared instance. The feature works only when:

• Your repository is linked to Scalingo via the GitHub or GitLab integration.
• The target Scalingo app already builds successfully with a supported buildpack (or an explicit buildpack is declared).
• Your account has enough container credits; each review app consumes a container until the PR is merged or closed.

If any of these conditions cannot be met, you must fall back to manual environment creation or a shared staging app.

Option Comparison

Aspect	Manual (CLI/API)	Automated (GitHub/GitLab integration)
Setup effort	High – write scripts, manage tokens	Low – one‑click enable in dashboard
Trigger	Explicit CLI command or API call	PR open / synchronize / close events
Teardown	Manual scalingo --app <name> destroy	Automatic on merge or close (configurable timeout)
Cost control	Full – you decide when to spin up/down	Limited – relies on auto‑destroy; set a max‑age guard
Best for	Ad‑hoc testing, one‑off experiments	Continuous CI/CD pipelines, team‑wide PR validation

Trade‑offs

Automated integration removes operational overhead but gives you less control over naming (Scalingo generates pr‑‑) and exact spin‑up timing. Manual creation lets you pick a stable name, attach custom add‑on plans, or delay creation until a specific CI stage passes. Both approaches share the same buildpack detection and add‑on provisioning logic, so build failures appear identically.

Key cautions:

• Review apps count against your container quota; enable an auto‑destroy timeout (default 7 days) to avoid runaway costs.
• Database migrations must be idempotent because each review app provisions a fresh PostgreSQL/Redis instance.
• Custom domains are not supported; only the generated https://.scalingo.io URL is available.
• Monorepos often need an explicit BUILDPACK_URL or a scalingo.yml buildpack field to avoid detection errors.

Concrete Implementation (Automated)

1. Link the repository – In the Scalingo dashboard, go to Apps → → Settings → GitHub/GitLab and click Connect. Grant the required permissions.
2. Enable Review Apps – Still in Settings, toggle Review Apps on. This creates the webhook that listens for PR events.
3. Add scalingo.yml at the repository root (or in the app’s root folder for monorepos):

   reviewapps: true
   formation:
     web: 1
     worker: 0
   addons:
     - postgresql: starter
     - redis: starter
   buildpack: https://github.com/scalingo/go-buildpack   # optional, forces a buildpack
   

   The formation block defines the process types and default container count per review app. Adjust to match your production formation.
4. Push a pull request – Open a PR against the default branch. Scalingo will create a new app named like myapp-pr-42-abc123, run the build, provision the add‑ons, and post a deployment status back to the PR.
5. Verify the environment – In the PR checks you’ll see a link “View deployment”. Click it or run:

   # Run from any machine with the Scalingo CLI authenticated
   scalingo --app myapp-pr-42-abc123 run bash
   

   Inside the container you can run rails db:migrate, npm test, or any smoke test.
6. Inspect logs –

   scalingo --app myapp-pr-42-abc123 logs --tail 100
   

   Confirm that the web process starts and that the add‑ons report “provisioned”.
7. Confirm auto‑destroy – Merge or close the PR. Within a few minutes the review app disappears from the dashboard and the container credit is released. You can also enforce a hard limit:

   scalingo --app myapp-pr-42-abc123 env-set REVIEW_APP_TTL=86400   # 24 h max lifetime
   

Validation Checklist

• Build succeeds – No buildpack detection errors in the deploy log.
• Add‑ons present – scalingo --app <review-app> addons lists PostgreSQL and Redis with provisioned status.
• Health endpoint reachable – curl -I https://myapp-pr-42-abc123.scalingo.io/health returns 200 OK.
• Auto‑destroy works – After PR merge, the app no longer appears in scalingo apps and container usage drops in the dashboard.

Limitations & Practical Checks

Review apps cannot use custom domains, so end‑to‑end tests that rely on a fixed hostname must be adapted to the generated URL. Because each review app gets a fresh database, any seed data required for tests must be applied in the migration or a post‑deploy hook. Monitor the Container usage panel in the Scalingo dashboard daily; a sudden plateau indicates a review app that failed to self‑destroy.

If you hit the container limit, either raise the quota or tighten the REVIEW_APP_TTL and/or disable Review Apps for low‑traffic repositories.