Deploy strategies

Deploying the files is the easy half. The half that decides whether a ship is smooth or dramatic is what happens right after the files land — the post-deploy action. Pick it well and a push turns into live code with no fuss; pick it carelessly and you either run stale code or drop your users mid-request. This guide is how to choose.

The core problem

A deploy copies new files in, but your app keeps running the old code until the process restarts. So every deploy has to answer one question: reload now, or later? The post-deploy action is that answer, and Falix gives you a menu:

Whatever you set applies to automatic deploys too, not just manual ones — so with restart selected, a push becomes live code with zero clicks.

The default: restart

For the vast majority of apps — a bot, a web API, a website — restart is the right answer and the one to reach for first. Files copy, the process restarts, and the app comes up on the new code within seconds. A brief blip while it reboots is the whole cost, and for most projects that's invisible.

If your project needs to compile or assemble before it can run (TypeScript to JavaScript, a Go binary, Composer dependencies), pair restart with post-deploy commands so the build finishes before the restart — Build steps on deploy has the recipes. The order is always: copy files → run build commands → restart on the freshly built result.

The review flow: "none", then restart yourself

For a risky change — a big refactor, a migration, a release you're nervous about — set the action to none. The files land, but your app keeps happily running the old code. You then:

1. Look over the deployment log and the incoming files.
2. Restart when you're ready and watching — ideally at a quiet hour.
3. Keep the Console open to catch a bad boot immediately.

This trades the convenience of auto-restart for a human checkpoint. It's the strategy for the deploy you don't fully trust — and if it does go wrong, the Git page's deployment history lets you pin the last good commit and roll straight back.

🎯 Good to know: "none" doesn't mean the deploy failed — it means the files are staged and waiting. The new code goes live the moment you restart, on your schedule, not the push's.

Stop-then-start, and the stubborn process

Most of the time restart is enough. Two cases call for something heavier:

• A clean-slate boot. If your app leaves state behind that a quick restart doesn't clear — a lock file, a stuck port — a stop followed by a manual start gives it a fuller reset than a restart does.
• A process that won't let go. If a plain restart leaves the old code somehow still running (a child process, a hung handle), kill or hard restart force-ends it. Reach for these only when a normal restart demonstrably isn't cutting it — they're blunt on purpose.

Timing a deploy around players

Game servers change the maths. A restart interrupts everyone connected — Minecraft players get dropped, a match resets. Most game servers aren't deployed from Git at all (you manage them through the panel's own pages), but if you do deploy files to one, or you run any app with live users, timing matters:

• Deploy at a low-traffic hour. The fewer people connected, the cheaper the restart.
• Warn first. On a Minecraft server, a say Restarting in 60s before the restart is basic courtesy — and you can automate exactly that with a Schedule: a Command task to warn, then a Power action to restart, running in order.
• Consider "none" plus a scheduled restart. Set the deploy action to none so the files stage without interrupting anyone, then let a Daily schedule restart the server at 5 AM when nobody's on. The new code goes live during the quiet window, hands-off.

💡 Tip: Pairing a none deploy with a scheduled off-peak restart is the calmest way to ship to anything with live users — the risky moment happens when nobody's watching but the automation.

Two habits that keep it calm

• Deploy from a branch you keep stable. Point the server at main (or a dedicated production branch) and do messy work elsewhere. Every push to the deploy branch goes live — treat it that way. More in Auto-deploy on push.
• Remember two quick pushes make two deploys. Push twice in a row and each fires its own deployment; they don't merge. Because every deploy takes the branch's newest commit, the last push in a burst is the state you land on.

Decision guide

Next steps

• Auto-deploy on push
• Build steps on deploy
• Automate your server with Schedules