Staging vs production: hosting multiple versions of the same site

Once a static site is more than a one-off, you usually want at least two versions of it: the one people actually see, production, and one you can safely test changes on before they go live, staging. If every deploy overwrites the same live link, there's no safe place to try something first, and every change becomes a small gamble.

Why a single live URL isn't enough

Without a separate staging environment, testing a change means one of two things: editing the live site directly and hoping nothing breaks, or running everything locally, where you can't easily share what you're testing with anyone else. Neither is great once more than one person is involved, or once the site matters enough that a broken deploy actually costs you something.

What you actually need

A way to deploy the same project more than once, with each deploy getting its own separate, shareable URL, so staging and production coexist instead of overwriting each other. Critically, this should be lighter than spinning up a whole second hosting account or project from scratch every time you want to test something.

How this works with projects and variants

Flaash handles this with variants, deployable copies of the same project. Each variant gets its own subdomain, so you might have myapp.flaash.live as production and myapp-staging.flaash.live as a variant you deploy to first:

Push a change to the staging variant, check it on its own live link, and only then update production, without the two ever colliding.

This also covers cases beyond staging and production specifically. Client review copies can be a variant the client sees, kept separate from what's already approved. A/B or design comparisons work as two variants of the same project, each with a shareable link, so you can compare them side by side. And historical snapshots can stay live at their own subdomain while you iterate on the next version.

Setting it up

Create a project once, then deploy multiple variants under it whenever you need a new isolated copy. Each is a fresh drop of a folder or .zip, with no extra configuration beyond naming the variant.

Frequently asked questions

How many variants can a single project have? There's no meaningful practical limit for typical use, staging, a couple of previews, and production comfortably coexist under one project without any conflict.

Does updating a staging variant affect production? No. Each variant is a separate deployable copy with its own subdomain; updating one doesn't touch the others until you explicitly deploy to them.

Can I promote a staging variant to production directly? The straightforward approach is to deploy the same files that are live on staging to your production variant once you're satisfied, keeping the two variants distinct rather than merging them.