> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/sfp-server/managing-your-sfp-server/starting-and-stopping.md).

# 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

```bash
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:

```bash
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

```bash
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:

```bash
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.

{% content-ref url="/pages/6PlNGUQR2fedKvv2mGNO" %}
[Backup and restore](/flxbl/sfp-server/managing-your-sfp-server/backup-and-restore.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.flxbl.io/flxbl/sfp-server/managing-your-sfp-server/starting-and-stopping.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.