Keep — a quiet custodian for small fleets of services

1The premise

An owner-operator with half a dozen to a dozen services — on a laptop, a Mac mini, EC2 instances, a server in another country — accumulates the same three problems: nobody knows what is running where, every machine holds API credentials its own way, and every SQLite database is backed up differently or not at all.

Keep answers all three with one deliberately small mechanism: give every deployment a cryptographic identity, then attach three passive capabilities to it — report status, lease secrets, deposit backups. One binary, one instance, one bucket, one key.

2The principle

Keep has no operational power over the services that use it. It does not start, stop, restart, deploy, restore, or run commands on their behalf. Each service remains independently operated and fully responsible for its own runtime behavior. Credentials and backups are opaque objects: Keep stores and returns them but never interprets their contents or uses them to act on anything.

The test for every future feature: does it merely record, store, or provide something — or does it cause another service to act? The latter stays out.

3What it holds

Engraving of an open muster-roll ledger on an oak lectern with quill and inkwell — Plate II · The Muster Roll — registry & status

A registry of services and deployments

Every enabled deployment reports in every five minutes over its mutually authenticated connection: health, running revision, uptime. Keep records only the latest state — it is an inventory, not a monitoring platform. An enabled deployment that falls silent for fifteen minutes shows offline. Each enabled deployment's running revision is compared against a desired revision declared at deploy time — by the administrator, or by a deployment for its own service — yielding a plain verdict: current, different, or unknown.

Engraving of an iron key cabinet in a stone wall, door ajar, rows of keys on hooks — Plate III · The Key Cabinet — secret custody

Custody of credentials

Secrets are named per service — openai, email-provider, aws-archive — encrypted under AWS KMS with the service, name, and version cryptographically bound to the ciphertext. Values enter through the administrative API and leave only through deployment leases; there is no endpoint that reads a secret back to an administrator — not even a fingerprint of it. Leases are soft: a freshness contract for cooperating clients, renewed twice a day, never mistaken for revocation — only the upstream provider can truly revoke a credential, and the design refuses to pretend otherwise.

Engraving of a vaulted stone strongroom with shelves of document boxes and sealed scrolls — Plate IV · The Archive — SQLite backups

An archive of database backups

Each service names its SQLite databases; each deployment validates and snapshots them consistently (VACUUM INTO), gzips the snapshot, and uploads it with a declared length and digest. Keep verifies size and checksum while streaming the compressed bytes into a versioned S3 bucket — never spooling them to its own disk, never looking inside. Backups are retrievable only by an administrator, and every download is an audit event. There is no restore endpoint: restoration is a human decision, made with a downloaded file.

4How it speaks

Everything is an API. There is no web console, no sessions, no passwords. Two kinds of principal exist — administrators and deployments — and both authenticate the same way: mutual TLS with pinned Ed25519 keys. Each machine generates its own key and self-signed certificate; the administrator registers the public-key fingerprint; the TLS handshake itself proves identity on every request. Private keys never leave the machines that generated them. The API lives on its own hostname — api.keepcentral.com — which is the only one that ever asks for a certificate; the page you are reading never will.

Deployment endpoints use /self — the authenticated key already says who is calling, so a client cannot name, or impersonate, anyone else:

PUT  /v1/self/status
GET  /v1/self/secrets
POST /v1/self/secrets/{name}/lease
POST /v1/self/databases/{name}/backups
POST /v1/self/desired-revision

A lease response, in its entirety:

{
  "name": "openai",
  "version": 7,
  "media_type": "application/json",
  "issued_at": "2026-07-12T16:00:00Z",
  "refresh_after": "2026-07-13T04:00:00Z",
  "soft_lease_until": "2026-07-13T16:00:00Z",
  "payload": { "api_key": "…" },
  "payload_base64": "…"
}

The deployment side of this conversation is a separate, open-source Go module: xoba.com/keep (MIT) — an SDK and CLI holding everything a service needs. Status keep-alives, secrets leased once and renewed in the background, backup upload, and one deploy-time write: a deployment publishing the desired revision of its own service. The server and the SDK are independent codebases that share no code; the wire contract published in the SDK repository is the entire boundary between them.

The server itself is one Go binary and one of everything it needs:

5What it refuses to do

Most of Keep's design is subtraction. It provides no web interface, no user accounts, no CI/CD, no redeployment or restart of anything, no automatic credential rotation, no automated database restoration, no git-provider integrations, no metrics or log aggregation, no remote command execution of any kind. A compromise of Keep is treated, honestly, as a compromise of everything it holds — which is precisely why it holds little, does less, and audits all of it.