Operations

Lifecycle commands for a running sfp server. Every command takes --tenant (lowercase letters, numbers, hyphens) and --base-dir (default ./sfp-server). Add --ssh-connection and --identity-file when running remotely from your workstation, or omit them when running directly on the server.

Registry credentials

Most lifecycle commands read the Docker registry credentials from environment variables, not from the tenant .env that init wrote (.env holds image/domain config, not registry secrets). sfp server start and sfp server update need them to log in and pull images. New shell session = re-export.

export DOCKER_REGISTRY="source.flxbl.io"
export DOCKER_REGISTRY_TOKEN="your-source-flxbl-pat"
# optional: export DOCKER_REGISTRY_USERNAME="USERNAME"   # for token-only registries

stop, status, logs, and scale do not pull images and do not need them. If start runs without them it logs a warning and proceeds — image pulls may then fail during compose startup.

Commands

Goal	Command
Start the server (creates volumes, pulls images, runs migrations)	`sfp server start --tenant <t> --base-dir /opt/sfp-server`
Stop the server (drains active workflows first)	`sfp server stop --tenant <t>`
Show service status	`sfp server status --tenant <t>` (append `--json`)
Check health	`curl https://sfp.yourcompany.com/health`
Tail combined server + worker logs	`sfp server logs --tenant <t>`
Tail one service	`sfp server logs --tenant <t> --service worker --tail 200 --follow`
Scale workers	`sfp server scale --tenant <t> --workers 3`
Update image / run migrations	`sfp server update --tenant <t>` (see Updating sfp server)

start flags: --restart|-r, --no-browser, --daemon, --config-file, --secrets-provider. stop flags: --force|-f (skip waiting for workflows), --drain-timeout <sec> (default 3600). update flags: --cadence|-r <production|beta|development|latest> (default latest), --docker-tag <tag>, --skip-backup, --continue-on-db-migration-failure, --force, --drain-timeout. scale --workers <1-10>. All take the SSH and secrets-provider flags.

`logs` flags

Flag	Default	Purpose
`--service <app\|worker\|caddy>`	combined `server hatchet-worker`	Restrict to one service. `worker` → compose service `hatchet-worker`; `caddy` → `caddy`.
`--follow`, `-f`	off	`docker compose logs --follow`
`--tail <n>`	`100`	Lines retrieved per service

The app service option currently maps to a compose service named app, which does not exist in this stack (the API service is server). Use --service worker or --service caddy; logs for the API default to server hatchet-worker.

Verify it is running

sfp server status output table — `sfp server status` — the service state table

sfp server status prints one row per container with Service / State / Health / Ports and an overall verdict (healthy, unhealthy, or stopped) derived from the compose state. The /health endpoint reports 200 with status: healthy and a components map; see Step 3 for its semantics.

Reading logs

tail of sfp server logs output — The tail of combined `sfp server logs` output

sfp server logs streams the combined server and hatchet-worker logs by default. Add --follow to tail live and --tail <n> to bound the lines per service. Raw container logs are available from the tenant directory:

cd /opt/sfp-server/tenants/<tenant> && docker compose -p <tenant> logs -f

Getting help

Channel	Where
Logs	See commands above
Status / health	`sfp server status`; see Step 3 for `/health` shape + 503 semantics
Support	Your sfp support channel