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 |
What an instance actually is
Open Instances from your server menu. An instance is an isolated profile on the same server, with its own:
- application, files, startup command, variables, and runtime version.
And it shares, with every other instance on that server:
- the port allocation, the RAM / CPU / disk limits, the firewall, the reverse proxy, and SFTP.
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.
The staging flow
1. Clone production into a staging instance
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.
2. Switch to staging
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.
3. Break things freely
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.
4. Keep it or ditch it
- It worked? Apply the same change to production: switch back (Stop and Activate → production) and make the change there, now that you know it's safe. Or promote by making staging your day-to-day slot.
- It broke? Just switch back to production. It boots exactly as it was before you started — no cleanup, no undo, because you never touched it.
Clone vs. a full second server
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 |
Deleting, permissions, and the free plan
- Deleting an instance deletes its files permanently — there's no trash for it. Keep a backup of anything you can't recreate before you delete a slot.
- Subusers need the Instances permission to create, activate, or delete instances. See sub-users.
- Free plan: you can create and activate instances, but only for free-plan applications. Premium-only apps can't be run in a free instance.
Verify it works
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.
Troubleshooting
- "Server must be stopped to switch" — use the Stop and Activate button; it stops then switches in one step.
- Activation ran an install — expected for some switches; let it finish before starting.
- Can't activate on free — the target instance uses a premium-only application; free instances run free-plan apps only.
- Where did my other instance's files go? — nowhere. Each instance keeps its own files; the inactive one is dormant, not deleted.