Spin up a full-stack preview environment in seconds, zero config

A pull request goes up. The reviewer wants to see it running, not just read the diff, so someone pings the team: can I get an environment for this? Depending on who's around, that could take an hour. It could take until tomorrow. By the time the environment exists, the reviewer has moved on to something else, and getting their attention back is its own task. What if the preview URL was already sitting in the PR before anyone had to ask?

What "zero config" actually means

Key takeaway: the config work happens once, at project setup, not every time someone opens a branch.

Upsun projects are built based upon a YAML configuration file that defines the app,its services and routes, and that file lives inside your git repo. What "zero config" refers to here is what happens after that file is in place and your environment variables are set. Once a project is set up, every new branch or pull request can get its own environment automatically, with no additional configuration required for that specific branch. Upsun's onboarding agent can even pre-generate that initial config file based on your repository, so even the one-time setup step is mostly automated. The longer version of the claim is "zero incremental config per branch for new environment deployments," but we decided to go with the shorter version for quicker explanation.

What happens when you open a branch

Key takeaway: the environment is created, rebuilt, and torn down automatically as the branch moves through its lifecycle.

With Upsun's git integration, opening a branch or pull request triggers an environment to spin up on its own. Push new commits, and it rebuilds. Merge or close the branch, and it's removed automatically. Your developers never have to fill out a ticket or do any manual steps to get their preview development environments..

What's actually running in there

Key takeaway: reviewers get the whole application, not just the code change.

The environment that gets created isn't a stripped-down preview of a single service or container. It includes the application code, a copy of the database, the search index, and the files the app depends on, plus an auto-generated URL that can be shared with anyone who needs to look at it: a reviewer, QA, a product manager checking a UI change. A lot of bugs and regressions only show up once the full stack is actually running together.

Why this speeds up review

Key takeaway: some bugs only exist once the full stack is actually running, and no amount of reading a diff will catch them.

Getting a live, working version of a change in front of a reviewer the moment a PR opens shortens the loop between making a change and getting it confirmed. It also catches a different class of problem. A CSS change that looks correct in a diff can still break at a specific screen width. A database migration can run clean in isolation and still conflict with existing, realistic data the moment something touches it. Nobody's waiting on a shared staging environment, and nobody's reviewing based on a description of what the code does instead of watching it actually run.

What happens to all these environments over time

Key takeaway: idle environments clean themselves up, so this doesn't turn into a pile of forgotten infrastructure.

Spinning up a full environment per branch raises an obvious question: doesn't this get expensive or messy once there are dozens sitting around? It's a fair concern industry-wide: Flexera's 2026 State of the Cloud Report found that 29% of cloud spend goes to waste, and idle compute sitting around unused, the same category a forgotten preview environment falls into, is the single largest contributor. 

Upsun automatically pauses preview environments that haven't been redeployed in 14 days, so idle ones stop consuming resources without anyone tracking them down manually. Pushing new code or resuming a paused environment brings it back. Merge or close the branch, and the environment is removed for good. Nothing here depends on someone remembering to clean up after themselves.

Why this matters for new developer adoption

Key takeaway: a developer can feel the value on their own the first time they open a pull request, without a demo or a sales call.

This is also why zero-config previews tend to work well as a self-serve trigger. A new developer using Upsun for the first time doesn't need to be walked through the value, they open a branch and the environment is just there. Watching a real, working copy of an app appear without doing anything extra tends to make a stronger case than anything written about it.

Ready to see a branch turn into a working environment on its own? Start a 15-day free trial and open your first pull request.

Frequently asked questions (FAQ)

Does this work with any Git provider? 
Upsun has native source integrations for GitHub, GitLab and Bitbucket, and each one creates preview environments for pull requests or merge requests automatically. Self-hosted instances work too: GitHub Enterprise, self-managed GitLab and Bitbucket Server. On any other Git host, you can still push to Upsun from your CI pipeline. You'd just have to script the automatic environment for each pull request yourself.

Do I need to write configuration for every new preview environment? 
No. Configuration lives at the project level and is set up once. New branches inherit it automatically.

What's included in a preview environment besides the code? 
A copy of the database, the search index, and the files the app needs, plus an auto-generated URL, matching what production actually runs.

Do idle preview environments keep costing money indefinitely? 
No. Environments that haven't been redeployed in 14 days pause automatically, and can also be paused or resumed manually at any time.