Reviewing More Than Code: How Ephemeral Environments Improved our PR Workflow

A developer team at an unnamed company built an ephemeral environment on AWS to improve pull request review workflows, triggered by GitHub Actions, which builds a Docker image, pushes it to Amazon ECR, and updates a preview URL for each PR. The system allows reviewers to interact with features in a production-like environment without local setup, addressing the increased volume of changes from AI-assisted development tools like Copilot.

We’ve all reviewed pull requests that looked perfectly fine in the diff, only to discover later that the application behaved differently. The reality is that reviewing code alone isn’t enough. Before merging, we still need to validate the feature, verify the user experience, and ensure nothing else has regressed. The goal is not just to approve code. The goal is to merge with confidence. This has become even more important with the rise of AI-assisted development. As tools like Copilot and agent-based coding assistants start opening pull requests for even small or incremental changes, the volume of changes increases — and so does the need to quickly and safely validate what those changes actually do in practice, not just in the diff. That led us to a simple question: What if every pull request came with its own preview link? Instead of pulling the branch, installing dependencies, and running the application locally, reviewers could simply open a URL and interact with the feature exactly as an end user would. No setup. No local builds. Just click, test, and merge with confidence. This approach is commonly known as a Preview Environment or Ephemeral Environment . The word ephemeral simply means short-lived . An ephemeral environment is a temporary, isolated deployment of your application that’s created for a specific purpose, commonly used to test, review, or validate a pull request. Instead of relying on a shared staging environment, each pull request gets its own dedicated environment that closely mirrors what will eventually be merged into the main branch. One of the biggest advantages of ephemeral environments is that they spin up a production-like environment with all of the application’s dependencies, configuration, and infrastructure already in place. Reviewers can simply open a unique preview URL and interact with the feature in a production-like environment. This means developers, QA engineers, product managers, and designers are all validating the same deployed application Unlike other environments such as development , staging , and production , which are shared and long-lived, ephemeral environments exist only for the lifetime of a single feature or pull request. Every change is isolated, allowing multiple features to be developed, tested, and reviewed in parallel without affecting one another. We wanted to improve our PR workflow by creating an environment that allowed the team to easily check the overall behavior of the code without putting in extra time. Approving pull requests is not just reviewing code. Our reviewers frequently needed to validate UI changes and backend behaviors before approving the pull request. That meant checking out branches, installing dependencies, configuring the application, and running it locally. Likewise, a product owner, stakeholder, or proof-of-concept reviewer needs to see the feature in action before giving feedback or approval. As the number of pull requests grew, especially with AI-assisted development, this process became increasingly time-consuming. So, we decided to build an ephemeral environment on AWS that can be accessed by every stakeholder and check the changes before the code is merged. As our application already runs on AWS, we wanted a solution that felt like a natural extension of our existing setup rather than introducing another deployment platform. We wanted to keep the solution simple and easy to maintain, so we built a lightweight deployment pipeline using: Let’s look into how the workflow operates: When a pull request is opened or updated, a GitHub Actions workflow is triggered. The workflow builds a Docker image containing our backend application, which also serves the React frontend as static assets. Since our frontend is bundled into the backend, we don’t need to deploy or manage a separate frontend service for preview environments. The Docker image is then pushed to Amazon ECR, and GitHub Actions updates an AWS Lambda function to use the newly built container image. Once the deployment completes, AWS Lambda exposes the application through a Lambda Function URL. Finally, GitHub Actions posts the generated preview URL as a comment on the pull request, allowing reviewers to open the application in their browser and interact with the feature without pulling the branch locally. There are many ways to build preview environments, such as using ECS, EC2, or Kubernetes. For our use case, however, AWS Lambda was the right fit because it aligned well with both our existing architecture and our team’s workflow. Our goal was to build a simple deployment platform, which would reduce the time between opening a pull request and confidently reviewing a feature. AWS Lambda gave us a simple way to achieve that while keeping the operational overhead low. For our team size and review workflow, Lambda provided a simple, reliable, and low-maintenance solution that integrated naturally into our existing AWS ecosystem. The growing adoption of AI coding assistants and autonomous coding agents has made ephemeral environments more valuable than ever. It’s becoming increasingly common to ask an AI agent to implement a small feature, fix a bug, or refactor a piece of code and open a pull request automatically. The challenge isn’t generating the code; it’s validating that the generated change behaves correctly. Ephemeral environments also help eliminate one of the most common frustrations in software development: “It works on my machine.” Because everyone is reviewing the same deployed environment, differences in local operating systems, dependency versions, or development setups become far less likely to influence the outcome. The conversation shifts away from reproducing an issue locally and moves toward validating whether the application behaves as expected. Beyond AI-assisted development, ephemeral environments align naturally with modern engineering practices such as Continuous Integration and Continuous Delivery CI/CD . They accelerate testing, shorten feedback loops, reduce dependency on shared staging environments, and allow multiple pull requests to be validated simultaneously. This not only improves developer experience but also enables teams to ship smaller, more frequent changes with greater confidence. Once we introduced ephemeral preview environments, the tone of our pull request reviews changed. Instead of relying only on the code diff and hoping the behavior matched expectations, reviewers could open the preview link, interact with the feature, and verify that everything still worked as intended. That made it much easier to catch UI issues, backend regressions, and problems introduced while resolving merge conflicts before the code was merged. It also opened the door for better collaboration across roles. Designers could review the actual implementation and confirm that spacing, alignment, responsiveness, and visual details matched the intended experience. QA engineers could test the feature earlier and report issues before they reached production. Product owners and stakeholders could see progress in a real environment and give feedback sooner. For proof-of-concept work, it became much easier to demonstrate ideas and validate direction before investing more time. That small shift had a big effect: What used to feel like a separate task, like pulling the branch, running the app locally, and manually checking the behavior, became part of the pull request itself. And as AI continues to accelerate software development, this workflow becomes even more valuable. Tools like GitHub Copilot and OpenHands can help engineers open pull requests faster, but faster code generation still needs a strong review process behind it. Preview environments give us a simple way to test those changes before they are merged and deployed. AI can help us move faster, but confidence still comes from seeing that the code actually works. Sometimes the biggest productivity gain is not writing code quickly. It is making it effortless to review, test, and trust the work before it gets merged. Ephemeral environments aren’t a new concept, nor is AWS Lambda the only way to implement them. Many engineering teams use platforms such as Bunnyshell, Vercel, Render, GitLab Review Apps, or Kubernetes-based solutions. Our implementation was tailored to our existing AWS architecture, allowing us to integrate preview environments into our workflow with minimal operational overhead while keeping the developer experience simple. If you’re interested in learning more about ephemeral environments and how different teams implement them, here are some excellent resources: Reviewing More Than Code: How Ephemeral Environments Improved our PR Workflow https://pub.towardsai.net/reviewing-more-than-code-how-ephemeral-environments-improved-our-pr-workflow-a9c2ccd9a300 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.