Automating Preview Environments with Scalingo Review Apps

The Problem: Testing PRs in Isolation

Testing feature branches in a shared staging environment often leads to “deployment collisions,” where one developer’s changes overwrite another’s, making it impossible to verify a specific Pull Request (PR) in a stable state. The goal is to create a disposable, isolated environment for every PR that mirrors production configuration without manual infrastructure overhead.

Prerequisites

• A Scalingo account with a valid API token.
• A GitHub repository linked via the GitHub Integration addon.
• A valid manifest in the repository root (either a scalingo.yml or a Dockerfile) to define the build and runtime requirements.

Configuring Review Apps

Review Apps use a “Base App” (typically your production or staging app) as a template for environment variables and addon configurations.

1. Navigate to the Scalingo dashboard and select your main application.
2. Enable the Review Apps feature in the settings.
3. Define the naming pattern for these environments. A common standard is pr- (e.g., pr-123), which allows for easy identification in the dashboard.
4. Push a commit to a feature branch and open a Pull Request in GitHub.

Deployment Workflow

Once a PR is opened, Scalingo triggers the following sequence automatically:

• Provisioning: A new, isolated application is created based on the naming pattern.
• Building: The platform executes the buildpack or Docker build based on the PR branch code.
• Addon Attachment: Declared addons (such as PostgreSQL or Redis) are provisioned specifically for that review app.
• Routing: A unique URL is generated and posted as a comment on the GitHub PR.

Verification and Diagnostics

To ensure the review app is functioning correctly, perform these checks using the Scalingo CLI.

1. Connectivity and Status

Run the following command to retrieve the unique URL and current status of the review app:

# Run on your local terminal with CLI installed
scalingo apps:info pr-123

Expected Result: The output should provide a public URL. Opening this URL in a browser should load the application content from the PR branch.

2. Environment and Addon Validation

Verify that the necessary environment variables and database connections were injected:

# Check environment variables for the specific PR app
scalingo env --app pr-123

Risk: Secret variables from the base app are not always copied automatically. If the app returns a 500 error, check for missing API keys or credentials in this output.

3. Log Analysis

If the application fails to start, inspect the startup sequence:

# Stream logs to identify build or runtime crashes
scalingo logs --app pr-123

Expected Result: A successful deployment ends with a log entry indicating the web process is listening on the assigned port.

Resource Management and Recovery

Scenario	Action	Command/Method
App fails to start	Redeploy via new commit	git commit -m "fix" && git push
Stale PR environment	Manual destruction	scalingo apps:destroy pr-123
Quota limit reached	Delete oldest review apps	Scalingo Dashboard > Apps

Limitations to Consider

• Quota Consumption: Review apps count toward your total application limit. High PR volume can lead to plan exhaustion.
• Build Persistence: If you change the buildpack in the base app, existing review apps will not update; they retain the image created at the time of the PR’s opening.
• Statefulness: Databases provisioned for review apps are empty. You must implement a seeding script or a data migration strategy to populate the preview environment.