Skip to main content
Slowave is designed to work without any configuration on a freshly installed machine — it discovers a sensible runtime root automatically using the OS user’s native application-data directory. When you need to relocate data, change ports, tune timeouts, or work around native library conflicts, environment variables give you fine-grained control over every runtime aspect of Slowave.

Runtime data location

Slowave isolates all runtime artifacts under a single per-user root directory. The database, daemon PID file, logs, backup archives, and setup sentinel all live beneath this root. The default varies by operating system: Run slowave doctor at any time to print the effective root and database path for your current environment.

Environment variables

The table below covers every variable that Slowave reads. Variables with no default must be set explicitly; variables with a default apply that value when the variable is absent.

Choosing between SLOWAVE_HOME and SLOWAVE_DB

SLOWAVE_HOME and SLOWAVE_DB cannot be set at the same time. Slowave raises a RuntimePathError immediately if both are present. Unset one of them.

SLOWAVE_HOME (recommended)

Moves the complete runtime tree — database, PID file, logs, backups, and sentinel — to the directory you specify. This is the right choice for CI, Docker containers, multi-user servers, and any installation where you want full control over where Slowave stores data.

SLOWAVE_DB (legacy)

Points Slowave at a specific SQLite file and uses its parent directory as an ad-hoc runtime root. This exists for backward compatibility with scripts that pre-date SLOWAVE_HOME. For new setups, prefer SLOWAVE_HOME.

The —db flag

In addition to environment variables, every CLI command accepts a --db flag that overrides the database path for that single invocation. This is convenient for one-off inspections of a specific database file without affecting the rest of your environment:
The --db flag applies only to the CLI. The running daemon always uses the path resolved from the environment at startup.

Port assignment

Slowave assigns port numbers lazily. The first time the daemon or dashboard starts, it scans loopback ports from the base value upward (starting at 8766 for the daemon and 8765 for the dashboard) and persists the first available port to a file in the runtime root (daemon.port and dashboard.port, respectively). Subsequent starts reuse the persisted port. To pin a port explicitly, set the environment variable before starting the daemon:

KMP_DUPLICATE_LIB_OK

On macOS, FAISS and ONNX Runtime can bundle different versions of the OpenMP runtime. When loaded in the same process they may trigger a hard abort. The CLI sets KMP_DUPLICATE_LIB_OK=TRUE automatically at startup to prevent this. If you invoke Slowave’s Python internals directly from your own code, you may need to set this variable before any imports:
Do not set this variable on Linux or Windows unless you have independently confirmed the same conflict exists in your environment.

Example: CI or container setup

In a Docker container or CI runner, use SLOWAVE_HOME to place all Slowave data in a predictable, writable directory:
This keeps the container image clean and allows you to mount or discard the runtime data as needed between runs.