GuidesOnly show guides for your app
GuidesGuidesMake your server redeploy itself when you push — via webhooks for connected repos, or scheduled pulls for public URLs — and roll back when a deploy goes wrong.
Once deploying from Git works, the next step is to stop pressing Deploy yourself. Falix can redeploy the moment you push, or on a timer, and it keeps a history you can roll back through when something ships broken.
| At a glance | |
|---|---|
| You need | a server with a repository already linked on its Git page |
| Plan | any |
| Time | ten minutes |
How your repo is linked decides what's available:
| How the repo is linked | Trigger | What happens |
|---|---|---|
| OAuth-connected (GitHub / GitLab / Bitbucket) | webhook | every push to your branch redeploys on its own, usually within seconds |
| Public repo by URL | scheduled pulls | Falix checks the branch every 1, 6, 12, or 24 hours and deploys when there's something new |
Turning on auto-deploy is what registers the webhook for connected repos. With a URL repo you can always press Deploy by hand between scheduled checks. Pick whichever matches how you linked the repo. If you want push-to-deploy specifically, connect the account rather than pasting a URL.
A deploy copies files in, but your app keeps running the old code until it restarts. That's what the post-deploy action decides. You pick one of:
| Action | When to use |
|---|---|
| restart | almost everyone — once files are copied, the server restarts and your app boots on the new code |
| start | the server is normally stopped |
| stop | just bring it down |
| none | review before restarting yourself |
| kill or hard restart | a plain restart isn't cleanly ending the process |
Whatever you choose applies to automatic deploys too, not just manual ones — so with restart selected, a push turns into live code with no clicks from you.
If your project has to compile or install before it runs, pair the action with post-deploy commands — see Build steps on deploy.
Every deploy is recorded with its status on the Git page — a quick glance tells you whether the last push actually landed or failed partway. When a deploy ships a broken commit, you don't have to scramble to fix forward: open the deployment history and pin a known-good commit to roll back to it. The server redeploys that exact commit's files, and you're back to working while you sort out the fix on your own time. The history isn't trimmed — your past deploys stay listed (shown in pages), so you can always look back and pin an older one.
🎯 Good to know: Rollback is the safety net that makes push-to-deploy feel safe rather than reckless.
A few habits make auto-deploy calm instead of scary:
main (or a dedicated production branch) and do your messy work on other branches. Every push to the deploy branch goes live — treat it that way..env and data files stay put unless the repo overwrites them by name. If a repo file would clobber something you want to keep, add its path to the deploy's exclude paths so it's protected from being overwritten. See Keep secrets out of Git.Push a tiny, visible change — bump a version string, tweak a log line — to your deploy branch. A webhook repo should redeploy within seconds; a scheduled repo on its next interval (or when you press Deploy). The Console shows the restart and your changed output. That's the whole loop working without you.