Platform
ScaiWave ScaiGrid ScaiCore ScaiBot ScaiDrive ScaiKey Modellen Tools & Services
Oplossingen
Organisaties Ontwikkelaars Internet Service Providers Managed Service Providers AI-in-a-Box
Kenniscentrum
Ondersteuning Documentation Blog Downloads
Bedrijf
Over ons Onderzoek Vacatures Investeren Contact
Inloggen

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.
  • 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.

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

Updated 2026-07-13 09:41:42 View source (.md) rev 2