Deploy

Push local Based code to your VPS, rebuild the container, and verify the server came back.

Usage

terminal
based deploy

Options:
  --skip-server   Only rebuild and upload the static site
  --skip-web      Only rebuild the server container

What it does

  1. Builds the static site and uploads it to /var/www/based-web
  2. Syncs the server code with rsync
  3. Runs docker compose build, fixes data ownership in a throwaway root container, then up -d --wait
  4. Polls GET /health and compares the reported version with your local packages/server/package.json

Because the rebuild finishes before the swap, up -d --wait replaces the old container only once the new image is healthy — the API is not down for the length of the build.

If /health cannot be reached, or reports a version other than the one you just shipped, the command prints the mismatch and exits 1. A deploy that says nothing but left the server on the old code is worse than a failure, so this is the one thing based deploy refuses to be quiet about.

terminal
curl https://based.yourdomain.com/health
# { "status": "ok", "version": "0.1.0", "projects": 2 }

When to use it

Run based deploy when you have changed the Based server code — the API layer, auth, middleware, or any server-side configuration — or the docs site, and want those changes live.

What it does not touch

Deploy only updates code and rebuilds the container. Project databases live in the based-data Docker volume and backups in the /srv/based/backups bind mount, so tables, rows, and user accounts survive every deploy. Take a snapshot with based backup <project> before a risky upgrade anyway.