Starting and stopping the server

All lifecycle operations run through the sfp server CLI against a tenant (--tenant <name>, the tenant created at sfp server init). start takes --base-dir when the server directory is not ./sfp-server; stop, status, and logs run from the directory that contains sfp-server/.

Start

sfp server start --tenant my-app --base-dir /opt/sfp-server

The command starts the stack detached and returns. Startup brings up the full stack — database, authentication, task queue, workers, and the application server — and the application server only reports healthy once its dependencies are up.

Verify the result:

sfp server status --tenant my-app
sfp server health --detailed

status lists every service with its running/health state. health --detailed performs per-component checks; --check-auth also validates the authentication stack. The same health information is served at https://<your-domain>/sfp/api, which returns overall status and per-component health as JSON — suitable for an external uptime check.

Stop

sfp server stop --tenant my-app

Stops the tenant's services. Before running compose down, stop waits for in-flight Hatchet workflows to finish, so a routine shutdown does not abort running work. The wait polls the server's /sfp/api health endpoint for activeWorkflows.total and proceeds once it reaches zero.

Flag	Effect
--drain-timeout <seconds>	Bounds the wait (default 3600). If workflows are still running when it elapses, stop logs how many and stops anyway — a stop always completes.
--force	Skips the wait and stops immediately, aborting any workflow that is still running.

The wait needs a reachable server URL, which stop reads from the tenant's DOMAIN. If the .env is missing or has no domain, stop proceeds without waiting.

A restart is stop followed by start. Applying a changed .env needs this restart (or sfp server start, which recreates the containers); docker compose restart reuses the running containers' existing environment and does not re-read .env.

After a host reboot

Container services are managed by the container runtime, and whether they come back automatically after a reboot depends on how the runtime is configured on your host (systemd units for rootless setups, or the Docker daemon's restart behaviour). After any reboot, run sfp server status and start the tenant if the stack is down, then confirm health at GET https://<your-domain>/sfp/api.

Reading logs

Every service logs to its container. The CLI wraps this:

sfp server logs --tenant my-app --follow            # server + standard workers
sfp server logs --tenant my-app --service worker --tail 200

Without --service the command shows the application server and the standard worker pool. --service worker narrows to the standard worker pool. The long-running worker pool is a separate service — read it directly with docker logs <tenant>-hatchet-worker-longrunning-1 (as with any single container). --tail defaults to the last 100 lines. Which log to read for which symptom is covered in the troubleshooting page.

Backup and restore