Clock Icon - Technology Webflow Template
min read

What is a Preview Environment?

Preview Environments help software teams increase their development velocity by reducing the time to merge new features.

What is a Preview Environment

Preview Environments help software teams increase their development velocity by reducing the time it takes to merge new features. They enable rapid feedback and iterative cycles, they enable teams to standardize a best practice for code review, and they ultimately reduce the workload on maintainers and team leaders who are responsible for dozens of Pull Requests every month.  

Preview Environments empower teams to shift their testing process to “pre-merge” where it’s significantly easier to find bugs, isolate responsibility, and make the appropriate changes. You can think of Preview Environments as a quality gate that allows features to be thoroughly tested and iterated upon in isolation. The net effect is feature parallelization or what is sometimes called “shifting left”. This is why we say, “Don’t merge until you preview” or “Keep dirty code out of main.”

Preview Environments fill the gap between local testing and your Staging environment or Production Environment. They are designed to test individual features or topic branches in a production-like environment that includes a full-stack of services. They have a purpose-driven or ephemeral life-cycle which means that they exist only as long as they are needed for review.  Configure it to create efficiency when you deploy code changes.

In practice, Preview Environments are often created and deleted in response to a pull request (PR) or merge request (MR) trigger.

A Preview Environment is often synonymous with pull requests (PR) environments, on-demand environments or ephemeral environments, with implementation details varying depending on the use case. When a new pull request comment is created a Preview Environment is also created.  When the PR is updated the Environment is updated. And when the PR is merged or closed the Environment is deleted.

With preview environments, you give your team the capability to have as many test environments as you need, when you need them, and only for as long as you need them. They primarily benefit maintainers and team leads who are overall responsible for speed of delivery and code quality but they are also a great cross-functional team tool because they benefit developers, testers, product team, and other key stakeholders.

As platforms like Netlify and Vercel have popularized previews for frontends and visual changes, the newly emerging preview environment is a natural complement for backends, databases, APIs, CLIs, Binaries, and, in general, any microservices application.  Many consider the capability to be a “game changer” and the “holy-grail” of DevOps.

Indicators that Preview Environments are right for your team


  • Releases are held up by buggy commits in a trunk branch
  • It takes a long time to merge new PRs/MRs
  • Your team lead spends a lot of their time pulling a code branch or branches to test or debug on their local machine
  • Your engineering team experiences “Code Freezes” in the development cycle or development process.
  • Your team has more than 4 developers using a shared test environment
  • Your team has frontend previews but no backend equivalent
  • Your team members are delayed by automated test queues
  • You want to improve collaboration between your cross-functional team of developers, testers, product, and other key stakeholders
  • You want to demo a new feature with a POC environment but have no easy way to provision one
  • You have to contact an engineer on the Ops or DevOps teams to get an environment

Common benefits of a Preview Environment

Below are common benefits when preview environments become an integral part of your development process.

Unburden your team lead or open-source maintainer

Development Team leads and open-source maintainers bear a huge amount of responsibility. To mitigate merge risks they will often want to see a running version of a Pull Request before they approve it.

Without Preview Environments this means pulling down the branch and running it in their local dev environment. This, of course, can be time consuming—multiply it by the number of developers on the team, and this becomes their whole job.  More importantly each maintainer may do this with a different environment set-up which makes standardization impossible and makes for an inefficient code review and deployment cycle.  If your application has a number of dependencies the challenge here is multiplied.

Catch bugs before merging

Identifying bugs prior to merging will save time and headaches for your Development Team lead. If you merge buggy code to a trunk branch, you’ve made an unforced error.

You won’t be able to cut a new release to production without 1.) Reverting your changes (=RISKY) or 2.) Waiting for the bugs to be fixed. And, of course, if you’ve broken a shared environment all testing will grind to a halt.

With a Preview Environment you can review code in a standardized, holistic way which drastically improves the odds of catching bugs early. You can use Preview Environments to run automated tests or conduct manual exploratory testing—either way your team lead will thank you for keeping dirty code out of a trunk branch.  

That’s not what I had envisioned

Ensuring continuity between what is designed and what is implemented is a ubiquitous organizational challenge. Preview Environments solve this by enabling your team to bring in all the key stakeholders early in the process.

Would you rather find out the product owner doesn’t like how something was implemented right after you code it, or a week later when they see it for the first time? Create end to end visibility across your entire organization.

Standardizing how you operate

Preview Environments enforce a best practices process that can be replicated across all of your teams.

For example how one team lead pulls code to run in their local environment will not necessarily match how another does it. Preview Environments as part of your Continuous Integration represent a best practice that all teams can follow.

Circumvent the automated test queue

As automated testing matures for any project, the queue against a single or limited number of environments becomes its own bottleneck.

This “queuing effect”—waiting up to several hours for tests to run—will only grow over time and continue to slow your team down. A Preview Environment enables faster feedback loops. Previewing can be done in parallel so that a single buggy commit does not hold up the entire forward progress of all the working commits.

Reviewing test environment models

Figure 1- Compare and Contrast Table
Figure 2a- Persistent - Shared Test Environment Model - Highly Inefficient. This is the most commonly used model across the software industry. 

Figure 2b- Preview Environment Test Environment Model - Highly Efficient. Emerging in prevalence. For fast growing teams who want to move quickly.

Figure 2c- Hybrid Test Environment Model - Efficient.  Emerging in prevalence.  For teams that want to move quickly while mitigating risk.

Common challenges of a Preview Environment

Test Data

Reviewing against a relevant set of data is critical to the process for many applications. For Preview Environments to be effective in this scenario the database needs to be seeded with a relevant set of data. There’s a few common ways this can be done which we will address in separate resources that are coming soon.

Negotiating managed services

If you are relying on various managed cloud-based services for your application these can be a significant challenge to your effective use of Preview Environments. If the service you are using is stateless in nature, you can supply connection credentials to your Preview Environments via environment variables or secrets.

If you can use a containerized service to effectively “mock” a third party managed service such as using a Postgres container to mock your managed cloud service this is extremely effective. Your Preview Environments can be lightweight and ephemeral while providing the core functionality you aim to test against.

If you have a stateful service that cannot be represented as a container or a virtualized service, then you probably want to connect to it read-only, or not connect at all. If this is a sticking point for your particular application, you will want to look for an infrastructure-as-code based-solution that can help you create/delete instances of your managed service for your Preview Environment.

Dealing with serverless

Connecting environments to serverless platforms like AWS Lambda can be a point of friction. Fortunately many of these can be containerized as an effective substitute to run in your Preview Environments.

Dynamic URLs

Often many services will depend on calls to a static URL (i.e. Preview Environments have a dynamic URL which means you may have to do some work to ensure that your team can dynamically interact with key dependencies.

If dynamic URLs follow a predictable format as they do on Uffizzi, that can drastically simplify connecting your backend previews to your frontend previews on Netlify, Vercel, Amplify, etc.

At Uffizzi we are actively working on a solution to enable dynamic updating of backlinks to key services like OAuth and we look forward to posting about that in our Preview Environments Guide.

Getting started with Preview Environments

For certain teams and applications it may make sense to create your own preview tool, but we highly recommend avoiding this route if possible.

It’s extremely costly for two, three, or more engineers to set up, build, and maintain a custom preview environment tool—especially since there’s handful of solutions on the market that will likely fit your needs and which are constantly improving.

For teams who want Preview Environments on their own infrastructure, open-source Uffizzi is the only self-hosted solution of its kind. And for teams that want the ease of SaaS, Uffizzi Cloud provides teams a way to create a Preview Environment using our environments as a service model.  

Uffizzi integrates with any version control system, CI-provider, and container registry. Define your applications with Docker Compose, then use one of our GitHub Actions workflows or GitLab jobs for easy integration.

You can set up a working example in ~1 minute using our quickstart repo. It can be configured and deployed from GitHub and includes an automatic free account configuration on Uffizzi.

Josh Thurman