Deployments

Every deployment of a project is on its Deployments page, newest first, with its commit, what started it (a push, you, a rollback, an import), its status and how long it took. A deployment's page streams its build log live. The server's own Deployments page lists every project's deployments in one place, and a gold dot on its sidebar item means something is building.

#What a deploy does

1. Fetch: the commit's tarball is downloaded from GitHub into /srv/apps/<app>/releases/<sha>/. The server never holds git credentials.
2. Build: the install and build commands run as the app's own user, in a sandbox with the same restrictions as the app, plus network access for the package registry. The output streams to the page.
3. Start: the app's unit and env file are written, and the new build starts on the idle color, blue or green. The panel waits for its health check to answer.
4. Switch: the app's Caddy site points at the new color, requests in flight finish, and the old color stops. Visitors never see a gap.

Static sites skip the start step: Caddy serves the build's output folder directly, with no process.

systemctl status 'app-<app>@*'      # the app's two colors
ls -la /srv/apps/<app>/releases/    # its builds on disk
cat /etc/caddy/sites/<app>.caddy    # where its traffic goes

#Push to deploy

Pushes to the project's branch deploy automatically, through the GitHub App's signed webhook. GitHub shows each commit's deploy status. Redeploy builds the latest commit of the branch again.

#Rollbacks

Each past deployment has Roll back to this deployment. It reuses the build already on disk, so it's a restart, not a rebuild, and it switches with zero downtime like a deploy. The last few builds are kept.

#The build queue

One build runs at a time by default. Settings → Builds allows up to 4 at once, never two of the same project. The others wait in line and start on their own, and a waiting deployment's page says what it's waiting for.

A build can use twice its app's memory limit, so on small servers, one at a time is safest.

#Build caches and disk space

Each app keeps its own package cache (npm, yarn, pnpm, bun), which makes builds fast. Apps don't share caches, so one app can't tamper with another's packages.

• When the disk is under 25% free, a build first empties every app's cache over 256 MB, and its log says what was freed.
• Builds stop if the disk is under 15% free.

A disk alert warns you before that, at 80% full.