Deployment
ScaiLog runs in two shapes, and both use the same code and the same storage engine. The smallest is one binary writing to one SQLite file; the largest is a central server fed by a fleet of per-host agents. You pick the shape that fits your deployment, not a different product — scaling up is a configuration and operations decision, never a rewrite.
The two shapes#
- Standalone (one binary, one file).
scailog-server --standaloneembeds the agent role in the server process, opens the local Unix socket itself, and writes directly toscailog.db. This is a first-class supported mode (design invariant P6), meant for a dev laptop, a single host, or a small appliance. See Standalone. - Agent + server. A central
scailog-serveraccepts encrypted batches over HTTP; each host runs ascailog-agentthat terminates the SDK socket, encrypts PI immediately, caches locally in SQLite, and ships in batches. This is the distributed shape for production fleets. See Agent + server.
Both shapes authenticate the same way. API keys are the base mechanism; an optional OIDC/SSO plugin sits on top for human operators and the admin panel. See Authentication & API keys.
Scale is a deployment choice, not a rewrite#
ScaiLog uses SQLite with FTS5 at both tiers — the agent cache and the central store share one engine, one schema family, and one set of query idioms (design invariant P2). There is no second storage format to graduate to. When you outgrow a single file, you change the deployment, not the architecture:
- Replication — run WAL mode and stream the database off-box with
Litestream (to S3-compatible storage) or run rqlite for a replicated SQLite
cluster. Keep the
keymap.dbbackup retention short — it holds the keys whose destruction is how erasure works. - Sharding — split tenants across separate SQLite files, so each tenant's entries and keys live in their own database.
- Horizontal servers — run N
scailog-serverprocesses behind a load balancer over replicated or tenant-sharded storage.
The server, agent, and SDK are otherwise identical across these choices, so you can start standalone and grow into a replicated or sharded server without touching call sites, policy, or the wire format.
Installing#
ScaiLog ships as one Python package with optional extras. The base install is the pure-stdlib SDK; each running component adds the matching extra:
| Component | Install | Console script |
|---|---|---|
| SDK (emit only) | pip install scailog |
— |
| Central / standalone server | pip install 'scailog[server]' |
scailog-server |
| Per-host agent | pip install 'scailog[agent]' |
scailog-agent |
| Operator CLI | pip install 'scailog[cli]' |
scailog, scailog-ci |
| Everything | pip install 'scailog[all]' |
all of the above |
Use pip and a virtualenv (python3 -m venv .venv && . .venv/bin/activate). The
scailog-ci call-site validator ships in the base install (it is zero-dep). If
you run a console script without its extra installed, it prints a one-line
pip install 'scailog[extra]' hint rather than a stack trace — see
Troubleshooting.