• Docs
  • Login
Talk to an expertTry for free
Blog
Blog
BlogProductCase studiesNewsInsights
Blog

The case for preview environments with production data

preview environmentsdata cloningAI Agentsdeveloper workflow
03 September 2026
Greg Qualls
Greg Qualls
Senior Director, Product Marketing
Share
This post is also available in German and in French.

Before he joined Upsun, Andrew Kester spoiled the biggest sale of a client's year.

He was one of two or three web developers at a creative agency that did branding, logos, print, and websites. A design boutique was about to run its annual trunk show, and the discounts and featured brands were meant to stay secret until the reveal on Tuesday at noon. The client asked for a preview. The preview reached production. That kind of accident is the argument for preview environments with production data, and it explains why the mechanics of environment cloning matter more than they look.

"The home page of their website was here's the big reveal, and it was about two days early," says Kester, now a senior cloud support engineer at Upsun. "We'd pushed the wrong environment, or I forget what exactly happened, but some database got crossed somewhere. It was a mess."

Andrew tells the story in the latest Product Highlights episode. He has since spent years on the other side of it, on a support team staffed twenty four hours a day, every day of the year, with engineers in North America, South America, Europe, Japan, and Australia. 

The tickets range from product questions to sites under active attack from threat actors. He has seen what goes wrong at scale, which makes his favorite part of the platform a telling choice: the button that clones an environment.

What agencies did before environment cloning

The pattern Andrew describes will be familiar to anyone who has built sites for clients. A customer wants a new page, a new feature, a new coupon. They want to see it before it goes live. Nothing in the stack was designed to let them.

"One of the biggest challenges we always ran into was we'd have a customer that wanted a new site, a new feature, a new page, a new coupon, whatever, and being able to show that to them without affecting their production site," he says.

So the agency improvised. Copy the environment by hand and hope the copy is close enough. Or ship the new code to production behind a password check and hope the check holds. Andrew's assessment of that second approach is blunt: if the stars aligned and the client had the right password, the hidden part of the site would show, "but it was never really reliable."

Both approaches fail for the same reason. A hand-copied environment is a guess about production, and a feature flag on production is still production. Neither one gives you a place where being wrong is free.

What actually gets cloned

On Upsun Cloud™, a new environment is a branch operation rather than a rebuild. Push a branch, run upsun branch, or open a pull request, and by default the new environment inherits its parent's data and services, including databases, network storage, queues, and routing configuration.

If you want the code without the data, push with environment.clone_parent_on_create=False.

Upsun credits the speed of the copy to copy-on-write snapshots, which is what makes cloning routine rather than something you schedule.

Andrew's summary of the developer experience is three sentences long.

"You click a button. We clone your services. We clone the data."

The data part is what separates this from the preview links most teams have used. A static frontend preview tells you very little about a content-managed site. As Andrew points out, applications like WordPress, or the ExpressionEngine sites his agency ran, carry a database full of initialization state. Configuration, content types, relationships, the accumulated shape of a real installation. An empty database is not a smaller version of that. It is a different application.

Source integrations extend the same behavior to code review. With the GitHub or GitLab integration connected, build-pull-requests is on by default, so opening a pull request creates a live environment parented to the target branch, and pull-requests-clone-parent-data is on by default too, so that environment arrives with the parent's data already in place. 

Draft pull requests are included unless you turn them off. Reviewers get a URL instead of a checkout, which is the difference between reviewing code and reviewing the change. It is also what removes the queue for a shared staging server, a problem worth its own discussion.

Isolation is the part that lets you break things

Parity with production is only half the value. The other half is that nothing you do in the clone can travel back.

"All of the code changes, all the database changes are isolated, so there's no risk," Andrew says. "If I go in and change something, I'm not going to accidentally push it back up to production."

Upsun states this as a property of the platform rather than a practice teams have to maintain: environments are fully isolated by default, and nothing crosses between them unless you ask it to. Sync pulls code or data down from the parent. Merge pushes code up. Both are commands you run deliberately, which is the whole point.

That guarantee changes what a developer is willing to attempt. Andrew puts the old adage plainly, then corrects it. Move fast and break things does not work when the only place to move is production, because caution scales with consequences and you end up stepping carefully through every deploy. Give the same developer a disposable copy and the calculation inverts.

"If you break the entire database and you truncate it, who cares? Make a new one. Just copy it back in. It's one command."

A destructive migration you want to watch run once before trusting it is cheap when the blast radius is a branch.

Why AI coding agents need the same guarantee

The economics of a disposable production copy have changed again, because developers are no longer the only ones asking for one.

Greg Qualls, director of product marketing at Upsun, says customers increasingly want an agent to "test against real production data without interacting with production."

Both requirements have to hold at once. An agent working from an empty sandbox has hardware isolation and no context. It can't reliably validate a query plan, confirm a migration completes, or notice that a change breaks on the one content type that only exists in the real dataset. Upsun has made the case for stateful sandboxes on exactly this point: ephemeral sandboxes isolate compute but usually lack the production-shaped data an agent needs to check its own work.

Isolation matters more with an agent than with a person, because the failure modes are less predictable. A hallucinated destructive command or a runaway loop is a very different event inside a preview environment than inside production. Handing an agent a branch instead of production credentials is the propose-and-test workflow Upsun argues for, and it works because the branch is real enough to prove something and disposable enough not to matter.

What safe by default covers, and what it does not

Two details are worth knowing before you share a preview URL with a client.

Search engines are handled for you. Non-production environments without a custom domain are always hidden from search engines, and that behavior cannot be changed. Preview environments with a custom domain are hidden by default, and you can choose to make them visible.

Human access is not handled for you. A preview environment is reachable by anyone with the URL until you configur  HTTP access control, which gives you either username-and-password pairs or an IP allow/deny list in CIDR notation, set in the Upsun Console or with upsun environment:http-access.

Children inherit the parent's setting, though an environment that already exists needs a redeploy to pick up a change — so set it on the parent before you start sharing links. For teams cloning sensitive datasets, deploy hooks are the place to sanitize or anonymize data as part of the clone.

Andrew's trunk show incident was a workflow failure, not a permissions failure. The fix was never a better password. It was a place to put unreleased work that was not production, and that looked enough like production to be worth showing a client.

That place is now a button. Learn more about instant development environments on Upsun Cloud, or read the environment documentation to see how branching, syncing, and merging fit together.

Stay updated

Subscribe to our monthly newsletter for the latest updates and news.

Your greatest work
is just on the horizon

Free trial