Skip to content

Deployment Model

Jump to bottom
treedinteractive edited this page Jun 28, 2026 · 2 revisions

One File, Zero Infrastructure

A SERAPH store is a single .sfg file. Header, write-ahead log, append-only frame log. No database server, no cloud dependency, no sidecar files, no schema migrations. Copy it, email it, sign it, notarize it, archive it, or hand it to a verifier who has never seen it before.

Embedding Model Locked at Genesis

The model is declared once and bound into every watermark. A SERAPH store cannot silently absorb embeddings from a different model. The failure mode that silently corrupts every other hybrid system is made impossible. Change the model, rebuild the store. That's correct and intentional.

Single Writer, Universal Read

One designated writer owns all ingests. All other consumers have read-only access — query, traverse, verify. Read access requires no coordination; concurrent readers are safe against an append-only log. Write throughput is bounded by the writer, which can queue, batch, and deduplicate. Semantic memory writes are not a high-frequency hot path.

Distribution and Licensing Lifecycle

The binary is distributed through seraph-db.com and GitHub (github.com/Tree-D-Interactive-LLC/seraph), with compiled artifacts published as GitHub Releases. The package itself is generic — the same artifact for every user.

Unactivated mode. A freshly installed engine with no license operates in a restricted but fully supported state: it can open, read, search, traverse, and verify any .sfg file, including sealed secure stores. It cannot create new stores. This is not an error condition. It is the intended first experience for a developer evaluating the substrate with a received store — they can inspect everything the substrate does without committing to an account.

Free activation. Creating stores requires a per-user Free license. The activation flow mints a license bound to a unique customer UUID:

  • Browser flow (primary). seraph license activate opens the browser. The user creates an account (email only), the backend mints a license token (customer UUID, tier, validity) bound to their UUID, and the CLI fetches and installs it at the platform default path.
  • Headless flow. seraph license activate --email user@example.com triggers email verification. On confirmation, the license is minted and the CLI receives it. Suitable for CI, containers, and headless environments.

The activation endpoint is protected by CAPTCHA and rate limiting.

Every Free license carries a unique customer UUID. This UUID appears in the operator identity of every store the user creates, making Free-tier stores auditable and traceable to a specific account. A store found in the wild can be attributed to the license that produced it — whether Free, Commercial, or Enterprise.

Commercial upgrade. After purchase, the user receives a license token (download or email) and installs it with a single command:

seraph license install <path-or-token>

The CLI validates the token, places the license at the platform default path, and confirms the tier upgrade. The upgraded license unlocks the Commercial tier; to produce a secure store the application also supplies a writer key at store creation (for example, Python's writer_seed argument or the FFI create_with_writer entry point). With a writer supplied, every record is signed; without one, the store is non-secure but still tamper-evident. The licensor is never in the writer-key path.

Enterprise. The same license install flow, with the license issued through direct engagement rather than self-service.

License location. Per-user by default: %APPDATA%\SERAPH\license.key on Windows, ~/.config/seraph/license.key on Linux/macOS. The SERAPH_LICENSE_PATH environment variable overrides the default for non-standard paths.

CI/CD pattern. Activate once on a developer machine, then store the resulting license file as a CI secret (GitHub Actions secret, GitLab CI variable, etc.). In the CI job, mount it at a known path and set SERAPH_LICENSE_PATH. CI environments do not create new accounts per build — they reuse the developer's existing license. The same pattern applies to containers: SERAPH_LICENSE_PATH=/etc/seraph/license.key, license mounted as a secret.

Renewal. Licenses carry an expires_at timestamp. The engine warns at preflight when expiry is within 30 days. Renewal is the same command as installation — seraph license install <new-token> — with a fresh token from the renewal flow. Because the license carries no writer key, renewal never touches a store's writer attribution: existing secure stores continue to verify across a renewal boundary.

Upgrade and existing stores. Stores created at Free tier carry the user's Free-tier UUID in their genesis attestation. After upgrading to Commercial, new stores can be created in secure mode (whenever the application supplies a writer key) under the same UUID. Existing Free-tier stores remain non-secure — upgrading the license does not retroactively alter stores already on disk.

Clone this wiki locally