"Why did this change?" — and its evil twin, "why didn't this change?" — trip up almost everyone at first. The fix is a simple mental model: a few different things can change on your server, each moved by a different hand. Once you know which is which, nothing surprises you. This guide is that model.
| At a glance | |
|---|---|
| You need | any Falix server |
| Plan | any |
| Time | five minutes to read; saves hours of confusion |
Who changes what
Everything that can change on your server falls into one of these lanes:
| What changes | Who moves it | How |
|---|---|---|
| The panel & features | Falix | Ships automatically; you do nothing |
| Your files | You | File Manager, SFTP, Git deploys, template deploys |
| The runtime version (Node 20 → 22, etc.) | You | The version picker on the Settings page |
Dependencies (node_modules, vendor, .local) |
The application | Reinstalled on start / build, from your dependency files |
| A full reset of files | You (deliberately) | Reinstall, or switching the server's application |
The rest of this guide is just those rows, spelled out.
Panel updates are Falix's job
New pages, new buttons, bug fixes to the dashboard itself — those arrive on their own. You'll open the panel one day and something's better. This never touches your files, your config, or your data; it's the software around your server improving. There's nothing to install and nothing to opt into.
Your files only change when you change them
This is the big one. Falix does not edit the files inside your server. Your code, your configs, your worlds, your databases — they sit in /home/container exactly as you left them until you move them, through one of:
- The File Manager — edits and uploads in the browser.
- SFTP — a desktop client pushing files (Connecting over SFTP).
- A Git deploy — pulling your repo (Deploy from Git).
- A one-click template — writing starter files (One-click templates).
And a rule that saves you from a bad day: deploys and templates copy and overwrite by name — they never delete files that aren't in the source. A Git deploy replaces index.js if your repo has one, but it leaves your server-side .env, your uploaded assets, and your database files completely alone. That's why secrets live safely on the server and out of your repo (see Keep secrets out of Git). The flip side: if a template writes a file whose name matches one of yours, the template's version wins — so a template landing over your work overwrites same-named files only.
🎯 Good to know: "Overwrite by name" is the whole model of change on Falix. A file gets replaced only when something copies a file with the same name over it. Nothing else deletes your work.
Runtime versions are a picker you control
The version of Node, Python, Java, or whatever runtime your application uses is a dropdown on the Settings page (the Environment tab), and switching it is available on every plan. Falix doesn't silently bump you from Node 20 to Node 22 — you choose when. Switching the version swaps the runtime image your app starts with; it does not touch your files. You'd change it when a dependency demands a specific major version, and leave it on the default otherwise. See your language guide — for example Node.js — for which version to pick.
Dependencies rebuild themselves
Your installed packages are a special case: node_modules, PHP's vendor/, Python's .local — these aren't really yours to hand-manage. The Node and Python applications run npm install / pip install on every start from your package.json / requirements.txt, and build steps can add a compile. So if a reinstall wipes node_modules, you don't panic — the next start rebuilds it from your dependency file. Guard your source and data; let the platform rebuild the generated stuff.
Reinstalls: the one thing that wipes files
Two actions deliberately reset files, and both warn you first:
- Switching the server's application (Settings → Operations → switch application) — changing from, say, Node.js to Python reinstalls the server and wipes its files. A template deploy that has to switch your application does the same. The panel shows a warning before it happens.
- Reinstall (Settings → Danger) — reinstalls the current application; it can replace files with fresh copies.
Neither is something you hit by accident, but knowing they exist explains the scariest "where did my files go?" moment before it ever happens.
⚠️ Heads up: Before a reinstall or an application switch, take a backup. It's the difference between a reset you can undo and one you can't. Your managed databases survive a reinstall regardless — they live on separate hosts, not in your server folder.
What survives what — a quick reference
| Event | Your files | Your .env & data |
Databases | Schedules |
|---|---|---|---|---|
| Panel update | ✅ safe | ✅ safe | ✅ safe | ✅ safe |
| Git deploy | overwritten by name only | ✅ safe (not in repo) | ✅ safe | ✅ safe |
| Version switch | ✅ safe | ✅ safe | ✅ safe | ✅ safe |
| Restart | ✅ safe | ✅ safe | ✅ safe | ✅ safe |
| Reinstall / app switch | ❌ wiped | ❌ wiped | ✅ safe | ✅ safe |
Schedules and managed databases live in the panel and on separate hosts, so they ride through a reinstall untouched — only files in your server folder are at risk.