Cut your debug time by reproducing production on demand

If a bug only shows up under real production conditions, the fastest path to a fix is removing the guesswork about those conditions, not layering on more debugging tools. 

This guide walks through what changes when every branch gets its own preview environment, a full clone of production available on demand, and what that actually looks like day to day.

What changes when reproduction stops being the bottleneck

Key takeaway: fixing reproduction speed improves debugging on three fronts at once, not just one.

Most of the time lost to a hard-to-reproduce bug goes into getting it to happen somewhere you can actually see it, not into fixing anything once it does: pulling a data snapshot, comparing configs, waiting for the conditions to line up again. 

When you can clone production into an isolated environment on demand, that entire step collapses. The engineer working the bug gets a faithful copy of the system as it actually exists, with real data and real service configuration, instead of an approximation they have to build by hand.

That changes three things in practice:

• Faster reproduction. The environment starts from a real snapshot instead of a guess, so bugs that only show up under specific data conditions show up right away instead of after hours of trial and error.
• Safer experimentation. Because the clone is isolated, an engineer can poke at the actual failure condition, break it again, try something else, all without touching the live system.
• Immediate validation. A fix gets tested against the same data and configuration the bug happened in, not a staging approximation. "It works" actually means something before it ships.

How the cloning works

Key takeaway: the clone is fast because it copies what changed, not the whole dataset, so database size stops being the limiting factor.

On Upsun, every environment, whether it's created for a pull request, a feature branch, or a one-off debugging session, is built as a full clone of its parent, services included. Pushing a branch spins up an environment running the same stack production does, same runtime, same services, same config, not a stripped-down stand-in for it.

The database clone itself uses a copy-on-write mechanism at the storage layer, so it's fast regardless of how large the production database is. Rather than copying the entire dataset, the system snapshots metadata and only writes out the changes made inside the new environment. In practice, a full terabyte-scale database clones in under a minute, not the hours a traditional dump-and-restore would take.

Because production databases contain real customer data, Upsun lets you configure sanitization scripts in your deploy hook that automatically anonymize or scrub PII during the clone process, so the environment can stay realistic without exposing data it shouldn't.

What this looks like day to day

Key takeaway: the environment needs no manual upkeep; it's there when needed and gone (or paused) when it isn't.

An engineer investigating a hard-to-reproduce bug pushes a branch (or opens an existing preview environment) and gets a working copy of production, data and all, in the time it takes to grab coffee. They reproduce the failure against real conditions instead of guessing at them locally. Once they've confirmed a fix, they validate it in that same environment before it ever touches production. When the branch closes, the environment tears down. No manual provisioning, no environment left behind to manage.

If the environment sits idle between debugging sessions, it can be paused rather than deleted, so the state is still there the next time someone needs to pick the investigation back up.

See it in action

The short demo below walks through cloning a production environment, tunneling into the cloned database, and reproducing a bug end to end.

 Ready to see how fast reproduction actually gets? Start a 15-day free trial and clone your first environment today.

Frequently asked questions (FAQ)

Does cloning stay fast no matter how large the production database is? 
Yes. Upsun clones a full terabyte-scale production database in under a minute using a copy-on-write mechanism that snapshots metadata rather than copying the full dataset, so clone speed doesn't scale with database size.

Is it safe to use real production data in these environments? 
You can configure sanitization scripts in your deploy hook that automatically anonymize or scrub PII as part of the clone process, so the environment stays realistic without exposing data that shouldn't leave production.

What happens to the environment once the bug is fixed? 
It tears down automatically when the branch closes. If it's just sitting idle between sessions, it can be paused instead, keeping its state without continuing to run.