---
title: Deployment
path: deployment
status: published
---

# 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 --standalone` embeds
  the agent role in the server process, opens the local Unix socket itself, and
  writes directly to `scailog.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](/docs/scailog/deployment/standalone).
- **Agent + server.** A central `scailog-server` accepts encrypted batches over
  HTTP; each host runs a `scailog-agent` that 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](/docs/scailog/deployment/agent-and-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](/docs/scailog/deployment/auth-and-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.db` backup 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-server` processes 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](/docs/scailog/troubleshooting).