March 12, 2026·6 min read

Preview Environments for Every Pull Request

Miget Team

Merging code into your main branch can feel like a leap of faith. Even with a suite of automated tests, the shared staging environment is often a bottleneck where conflicting changes cause unexpected bugs. This slows down your entire development cycle. What if you could test every change in a clean, production-like environment before it gets merged?

This is where preview environments come in. By automatically creating a dedicated, ephemeral environment for every pull request, your team can test, review, and collaborate on new features in complete isolation. This modern approach to CI/CD eliminates staging bottlenecks and empowers you to ship code with greater speed and confidence.

What Are Preview Environments?

A preview environment is a temporary, fully-functional deployment of your application that is automatically created when a pull request (PR) is opened. It contains the specific code from that PR's feature branch, allowing anyone to interact with the changes through a unique URL.

The entire lifecycle is automated:

Created: A new environment is provisioned when a PR is opened.
Updated: The environment is redeployed with the latest changes on every new commit to the branch.
Destroyed: The environment and all its resources are automatically torn down when the PR is merged or closed.

This model is a significant departure from traditional, static environments.

Feature	Shared Staging Environment	Preview Environments
Lifecycle	Long-lived, persistent	Ephemeral, per-pull-request
State	Can become stale or broken	Always a fresh, clean deployment
Isolation	Single environment for all features	One isolated environment per feature
Scalability	A development bottleneck	Scales in parallel with your team
Cost	Always on, often oversized	On-demand, pay only for usage

These temporary, on-demand deployments are also known as ephemeral environments or pull request environments.

The Benefits of a PR-Based Workflow

Integrating preview environments into your development process fundamentally improves how your team builds software.

Faster Feedback Loops

Developers no longer have to wait for CI to pass and for a slot to open up on the staging server. A shareable URL is available within minutes of pushing code, enabling immediate testing and validation. This drastically shortens the code-commit-to-feedback cycle.

Improved Collaboration

Preview environments break down silos between engineering, product, and design. Instead of checking out a branch and running the app locally, stakeholders can click a link in the PR to review changes. Product managers can verify functionality, designers can check UI/UX implementation, and QA can run manual tests in parallel.

Reduced Risk of Bugs

By testing every change in an isolated, production-like environment, you catch integration issues, configuration errors, and other bugs before they ever reach the main branch. This prevents the classic "it works on my machine" problem and reduces the number of hotfixes needed after a release.

No More Staging Bottlenecks

A shared staging server is a common point of contention. One team's broken deployment can block everyone else. With preview environments, every feature is developed in parallel without interference. This is crucial for growing teams that need to increase their development velocity.

How Do Preview Environments Work?

The magic behind preview environments is a tight integration between your Git provider, your CI/CD system, and your hosting platform.

Trigger: A developer opens a pull request in a Git provider like GitHub. A webhook is sent from GitHub to the deployment platform.
Build: The platform checks out the code from the feature branch. It then builds a new container image for your application, either from a Dockerfile or by using buildpacks like migetpacks.
Provision: The platform spins up the necessary infrastructure. This includes:
- Deploying the new application container.
- Provisioning fresh databases or caches (e.g., PostgreSQL, Valkey) as Addons.
- Injecting the required environment variables and secrets.
Deploy & Notify: Once the application is running, the platform generates a unique, temporary URL (e.g., my-app-pr-42.migetapp.com). It then posts a comment back to the pull request on GitHub with a link to the live environment and the deployment status.
Update: If a developer pushes a new commit to the PR branch, steps 1-4 are repeated, updating the environment with the latest code.
Teardown: When the PR is merged or closed, another webhook triggers a cleanup process. The platform automatically deletes the application, its addons, and all associated resources, ensuring no costs are incurred for inactive environments.

Setting Up Preview Environments on Miget

Miget has built-in support for preview environments, allowing you to enable this powerful workflow with just a few clicks. There are no complex CI scripts to write or webhooks to configure.

Prerequisites

A parent Application deployed on Miget.
Your application's code hosted in a GitHub repository.
The Miget GitHub App installed and configured for that repository.

Configuration Steps

Here is how to enable preview environments for your application.

From the Miget dashboard, navigate to the application you want to use as the parent. This should be the app that deploys your main branch (e.g., main or production).
Go to the Settings tab for that application.
Scroll down to the Preview Environments card and click "Enable".
Configure the settings:
- Inherit Environment Variables: This is highly recommended. It securely copies all environment variables (including secrets) from the parent application to each new preview environment.
- Auto-create Addons: Enable this to automatically provision fresh, clean copies of any database or cache Addons (like PostgreSQL, MySQL, or Valkey) that are attached to the parent app. This ensures every PR has its own isolated data store.

Once enabled, Miget will automatically begin creating preview environments for every new pull request opened in your connected repository. A link to the live deployment will appear directly in the GitHub pull request interface.

Best Practices for Preview Environments

To get the most out of your new workflow, consider these best practices.

Use Database Seeding

Your preview environments shouldn't connect to your production database. Instead, use the Auto-create Addons feature to get a clean database for each PR. To make testing realistic, create a small, anonymized seed script that populates the database with essential test data when the application starts.

Manage Secrets Securely

Never commit secrets directly to your repository. Miget's "Inherit Environment Variables" feature is the best way to handle this. Secrets are stored securely on the platform and injected at runtime, so your feature branches don't need access to production credentials.

Optimize for a Fixed-Capacity Model

One concern with preview environments is cost. On other platforms, each environment incurs separate charges, which can add up quickly. Miget solves this with its fixed-capacity Resource model. You can run dozens of preview environments inside your existing plan without any per-environment billing. Our Fair Scheduler ensures that all your apps - production, staging, and preview - share the CPU and RAM efficiently.

Keep Them Fast and Lightweight

The goal is a fast feedback loop. Optimize your Docker images and build processes to be as quick as possible. Your database seed script should also be fast, populating only the data necessary for testing the application's core functionality.

Next Steps

Adopting preview environments streamlines your entire deployment workflow, enabling your team to build, test, and ship features faster and more reliably. By eliminating the shared staging bottleneck, you unlock true parallel development.