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 |
Two ways to trigger a deploy automatically
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.
Choose what happens after the files land
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.
History and rollback
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.
Keep it sane
A few habits make auto-deploy calm instead of scary:
- Deploy from a branch you keep stable. Point the server at
main(or a dedicatedproductionbranch) and do your messy work on other branches. Every push to the deploy branch goes live — treat it that way. - Watch the first automatic deploy. After you enable it, push a small change and keep the Console open. You want to see the deploy fire, the server restart, and the app come back up on its own at least once before you trust it unattended.
- Remember what survives. Auto-deploys use the same copy-only rules as manual ones: your server-side
.envand 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. - Two quick pushes make two deploys. Push to the deploy branch twice in a row and each push fires its own deployment with its own history entry — they don't merge into one. And because every push deploys the branch's newest commit, the last push in a burst is the state you end up on.
- Start small. Enable a webhook or the shortest schedule you're comfortable with, prove it works on a throwaway change, then let it run. You can turn auto-deploy off again at any time and go back to pressing Deploy by hand.
Verify it works
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.
Troubleshooting
- Pushed, but nothing deployed (webhook repo) — confirm auto-deploy is enabled and you pushed to the linked branch; pushes to other branches are ignored.
- URL repo never updates on its own — URL-linked repos don't get webhooks. Set a scheduled pull interval, or deploy manually.
- New code deployed but the app still runs the old version — your post-deploy action is probably none; set it to restart so the app reloads.
- A deploy broke production — pin the last good commit in the deployment history to roll back, then fix the branch before deploying again.
- A deploy failed partway — open its entry in the deployment history to read the error. See When a git deploy fails.