Build steps on deploy

Post-deploy commands are where compiling, bundling, and installing happen — up to 20 of them, run right after your code lands.

Some projects can't run straight from source: TypeScript has to compile, Go has to build a binary, a PHP web app needs its Composer dependencies fetched. Falix runs those steps for you after every deploy, with post-deploy commands on the Git page. This guide covers the common recipes.

At a glance
You need a server with a repository linked and deploying (see Deploy from Git)
Plan any
Time fifteen minutes

What post-deploy commands are

On the Git page you can add up to 20 post-deploy commands. After a deploy copies your files in, Falix runs them in order, inside your server's own environment, with your files — the same container your app runs in, so whatever that application provides (node, python, go, composer, your project's tsc) is on hand. Each command can be limited to run only when the server is online, only when offline, or in any state — useful when a build should happen while the app is stopped, or a warm-up should happen while it's up. Each also takes an optional delay (0–300 seconds), a pause before it runs, for the rare step that needs the one before it to settle first.

This is the place for build work: npm run build, tsc, go build -o app, composer install.

🎯 Good to know: These run once per deploy, right after the pull — distinct from the automatic dependency install (npm install, pip install) that the Node and Python applications do on every start.

Use the automatic install for grabbing dependencies, and post-deploy commands for turning source into something runnable. Here's how that looks for the common cases.

Recipe: a TypeScript project

A bare .ts entry file won't run on the Node application, so you compile to JavaScript first. Two approaches:

  • Post-deploy compile. Add a post-deploy command tsc (or npm run build if that's your build script), and set the Main file variable to your compiled entry point, dist/index.js. After each deploy, tsc produces dist/, and the server runs the built JavaScript.
  • Compile on install instead. If you'd rather not manage a post-deploy step, use the postinstall approach from the TypeScript Discord bot guide: a "postinstall": "tsc" script in package.json runs the compile during the automatic npm install on every start. Then you can skip post-deploy commands entirely — the build rides along with the normal start, and it works for any TypeScript project, not just bots.

Both end in the same place: a dist/index.js the Node application runs.

Recipe: Go

The Go application runs a prebuilt binary named app — nothing compiles at start. When you deploy Go source from Git, add the post-deploy command:

go build -o app

That compiles your project into the app binary the application expects, right there on the server after each pull. (The alternative is building locally with GOOS=linux GOARCH=amd64 go build -o app and committing the binary — but building on deploy keeps the repo source-only.) See Go on Falix for the full picture.

Recipe: a PHP web project with Composer

The PHP Web Server application does not run Composer for you — it just serves your site. If your project has a composer.json, install its dependencies with a post-deploy command:

composer install --no-interaction

That produces the vendor/ folder your code pulls in. (The separate PHP Composer application does run composer install automatically on start — use a post-deploy Composer command specifically for the web-server app, or whenever you want the install to happen at deploy time.)

Prefer the Packages page for plain dependencies

Post-deploy commands are for build work. For simply adding a library — express, requests, a Composer package — the Packages page in your server menu is the easier, safer path: it runs the real package manager, updates your dependency file for you, and flags outdated or vulnerable packages.

💡 Tip: Reach for post-deploy commands when you need to compile or assemble something, not just install it.

Verify it works

Trigger a deploy and watch the deployment log and the Console. You should see each command run in order with its output — tsc finishing, go build producing app, composer install writing vendor/ — and then the server start on the freshly built files. A command that errors shows a non-zero result in the log; fix it and redeploy.

Troubleshooting

  • command not found — the tool isn't part of that application's environment. go build only exists on the Go app, composer on the PHP apps, and so on. Commands run in your server's environment, not a generic shell.
  • Build runs but the app still runs old code — set the deploy's post-deploy action to restart so the app reloads after the build (Auto-deploy on push).
  • tsc runs but the server can't find the entry file — point the Main file variable at the compiled path (dist/index.js), not the .ts source.
  • Too many steps to manage — the 20-command limit is a ceiling, not a target. Most projects need one build command, or none if they build on install.

Next steps

Was this guide helpful?