Laravel Preview Environments: Why Every Pull Request Could Have Its Own App

In an announcement on September 28, 2026, Laravel Cloud introduced a new feature called preview environments. Each pull request could have its own deployed environment, which could be automatically cleaned up when the pull request was merged or closed. This innovation offered several advantages for modern Laravel development.

A preview environment was described as a temporary deployment specifically created for testing a particular code change. Rather than sharing a single staging environment, each developer could work on a feature in their own preview environment, avoiding interference with other developers' branches. Laravel Cloud's workflow automatically created a deployment when a pull request was opened, assigned it a unique URL, and updated the preview when new commits were pushed.

One of the key benefits was the connection between code review and application review. Reviewers could interact with the application by opening the preview URL, rather than having to understand the entire development environment. This was particularly useful for frontend changes, allowing reviewers to assess layout, mobile responsiveness, buttons, navigation, charts, loading states, error states, and more.

The announcement also highlighted the importance of scale-to-zero, a feature that allowed idle environments to scale down to zero when not in use, conserving infrastructure costs. When someone accessed a preview environment again, the necessary resources would automatically wake up. This was especially beneficial given the increasing use of AI coding agents that produced large numbers of code changes and pull requests.

There were several considerations to keep in mind when implementing preview environments. They should have their own database, cache, queue resources, and storage, separate from production. Environment variables should be defined specifically for the preview, and never assume that a temporary environment doesn't need security controls. Automatic cleanup was also an important aspect, with Laravel Cloud able to delete previews after they were merged.

These preview environments provided a closer-to-production testing environment, allowing developers to test real HTTP requests, database behavior, queues, email integrations, authentication, external APIs, browser behavior, and deployment configuration. By using preview environments for browser tests, sandbox integrations, and verifying build and deployment commands, configuration problems could be exposed before they reached production.

It was crucial to avoid connecting previews to production data, maintaining separate databases, caches, and services for previews to prevent any unintended modifications or actions.