Deploy from Git

Uploading files by hand gets old fast. The Git page pulls your code straight from a repository into your server, so shipping a change becomes: push to your repo, deploy, done. This guide gets your first deploy working.

Connect a repository

Open the Git page from your server menu. There are two ways to link a repo:

1. Connect an account — sign in to GitHub, GitLab, or Bitbucket with OAuth. You then pick from your repositories — public and private alike, most recently updated first — and this is what unlocks auto-deploy on push later.
2. Paste a public URL — any public repository works this way, including hosts like Codeberg. URL-linked repos deploy manually or on a schedule only, with no push webhooks — more on that in Auto-deploy on push.

Either way, once the repo is linked, choose the branch you want to deploy (usually main).

Deploy

Nothing is pulled until you say so. Press Deploy. Falix fetches the branch and copies its files into your server folder — /home/container, the root you see in the File Manager. Watch the deployment log finish, then head to the Console and press Start.

The one thing to understand: deploys copy, they don't replace

This is the semantics that saves you from a bad day, so read it once:

🎯 Good to know: A deploy copies files from the repo and overwrites any server file with the same name. It never deletes server files that aren't in the repo.

So your .env, your uploaded assets, your node_modules, and your local data files all survive a deploy — as long as your repo doesn't contain a file with the same name to overwrite them. That's exactly why the standard workflow keeps secrets in .env on the server and out of the repo entirely (see Keep secrets out of Git).

Your project layout has to match the application

Git puts your files on the server, but the application decides what to run, and each one looks for a specific entry file at the root of your server folder:

…and so on. If your repo's entry file has a different name or sits in a subfolder, either restructure the repo so the entry file lands at the root, or set the matching variable — the Main file for Node, the App py file for Python — on the Settings page. No premium needed.

Deploying one folder of a monorepo. If your repository holds several projects and only one belongs on this server, open the Git settings and set Sync paths — a list of up to 20 paths that limits a deploy to just those directories, so the rest of the repo never lands on the server. Exclude paths (also up to 20, applied after the sync filter) does the reverse, keeping named paths from being copied at all. Then point the Main file (or App py file) variable at wherever your entry file ends up inside the synced folder.

If your project needs a build step before it can run (compiling TypeScript, building a Go binary, installing PHP dependencies), that happens with post-deploy commands — see Build steps on deploy.

Verify it works

After Deploy → Start, the Console should show your app booting exactly as it would from hand-uploaded files — a web app logs its Listening on port … line, a bot logs its login. Files present in the File Manager plus an app that starts means your first deploy worked.

Troubleshooting

• Deploy succeeds but the server won't start — usually a layout mismatch: the entry file isn't where the application expects it. Fix the repo structure or the Main file variable. See My app won't start.
• Private repo won't link by URL — URL linking is for public repos. Connect the GitHub / GitLab / Bitbucket account with OAuth to reach private repositories.
• My .env got overwritten — your repo contains a file literally named .env. Remove it from the repo (and rotate any secrets that were in it), then keep only a .env.example in Git.
• Dependencies missing after deploy — for Node and Python they install on start from package.json / requirements.txt; other projects may need a build step. See Build steps on deploy.

Next steps

• Auto-deploy on push
• Build steps on deploy
• Keep secrets out of Git