GuidesOnly show guides for your app
GuidesGuidesTest risky changes without breaking the live thing — clone your production instance into a staging copy, experiment there, and switch back untouched if it goes wrong. Plus the honest limit: only one instance runs at a time.
Sooner or later you want to try something risky — a big dependency bump, a new plugin, a rewritten config — but not on the server people are using. Instances give you a safe place to do it. An instance is a second, isolated profile on the same server; you can clone your live setup into one, break things freely, and switch back to production untouched. This guide turns that feature into a staging workflow.
| At a glance | |
|---|---|
| You need | Any Falix server |
| Plan | All plans — on free, instances can only run free-plan applications |
| Time | Fifteen minutes |
Open Instances from your server menu. An instance is an isolated profile on the same server, with its own:
And it shares, with every other instance on that server:
You can have up to 10 instances per server. Think of them as save slots for the whole server: same hardware and address, different contents.
⚠️ Heads up — the one that shapes everything: because instances share a single port allocation and one set of resources, only one runs at a time. Staging isn't a second live server humming alongside production; it's the other slot. You stop production, activate staging, and now staging is what's running. This is the honest limit — plan around it, not against it.
On the Instances page, clone your production instance. A clone is a separate copy that includes its files, so you get an exact duplicate of your live setup to experiment on. Name it something obvious like staging.
💡 Tip: Clone rather than starting a fresh instance when you want to test changes against real data and config. A fresh instance starts empty — that's for running a genuinely different app in the other slot, not for staging a copy of what you already have.
Activating an instance requires the server to be stopped, so the panel offers a Stop and Activate button that does both. Activation swaps the files and config over to the staging instance; some switches trigger a short install step. Your production instance's files sit safely on the side, exactly as you left them.
Staging is now what's running. Update that dependency, install that plugin, rewrite that config, start it, and test. Nothing you do here touches production's files — they're a different profile.
Instances are the right tool when you want an experiment slot on the same server and you're fine that only one runs at a time. When you genuinely need production and staging live simultaneously — both reachable, both running — that's a second server, not a second instance. The Clone server action (Settings → Operations) makes a full independent copy on its own allocation; see Cloning a server.
| Need | Use |
|---|---|
| A safe slot to test in, one-at-a-time | A staging instance (this guide) |
| Both prod and staging running at once | A second server (clone server) |
| Just testing code changes safely | Git feature branches |
Activate your staging instance and open the Console — it's running staging's files and startup. Make a visible change (a new log line, a config value), confirm it. Then Stop and Activate back to production and confirm your original, unchanged setup returns. That round trip is the safety net working.