Towards AIblog

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

Tuesday, August 25, 2026Leapfrog TechnologyView original
Author(s): Leapfrog Technology Originally published on Towards AI. 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. What is an 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. Problem we wanted to solve 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. Building an ephemeral environment on AWS 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: GitHub Actions Docker Amazon ECR AWS Lambda Lambda Function URLs 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. Image of GitHub PR comment Why AWS Lambda worked for us 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. No additional domain or routing configuration: Lambda Function URLs provide a public HTTPS endpoint out of the box, so each deployment is immediately accessible without configuring API Gateway, load balancers, or DNS. Seamless CI/CD integration: GitHub Actions simply pushes a new container image to Amazon ECR and updates the Lambda function, making preview environments available within minutes. Cost-effective for temporary environments: Since preview environments are only accessed during code reviews, Lambda’s pay-per-invocation pricing model helps keep infrastructure costs low. Minimal operational overhead. Because AWS manages the underlying infrastructure, our team could focus on improving the developer experience instead of maintaining preview servers. For our team size and review workflow, Lambda provided a simple, reliable, and low-maintenance solution that integrated naturally into our existing AWS ecosystem. When should you use an ephemeral environment? 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 […]