GuidesOnly show guides for your app
GuidesGuidesA deploy copies files, but what happens next is your call — the post-deploy action. Restart for most apps, the review flow for risky ships, and how to time a deploy around players on a game server without yanking the rug.
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.
| At a glance | |
|---|---|
| You need | a server deploying from Git (see Deploy from Git) |
| Plan | any |
| Time | ten minutes |
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:
| Action | Pick it when |
|---|---|
| restart | almost everyone — files land, the app restarts, the new code is live |
| start | the server is normally stopped and you want the deploy to boot it |
| stop | you're taking it down (a maintenance window, a decommission) |
| none | you want to review before restarting yourself |
| kill / hard restart | a plain restart isn't cleanly ending the old process |
Whatever you set applies to automatic deploys too, not just manual ones — so with restart selected, a push becomes live code with zero clicks.
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.
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:
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.
Most of the time restart is enough. Two cases call for something heavier:
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:
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.💡 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.
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.| Situation | Action |
|---|---|
| Normal app, normal change | restart |
| Needs to build first | restart + post-deploy commands |
| Risky change, want to eyeball it | none, restart by hand while watching |
| Live users you don't want to drop | none + a scheduled off-peak restart |
| Old process won't die on restart | kill / hard restart |