`@noy-db/at-*` — Sealing-key providers (trusted hosts)

How a vault goes online without the user holding a key. noy-db encrypts everything on the client under keys derived from a secret, so normally only the user can open their vault. The at-* family covers the server-side case: a host you control — a Lambda, an EC2 box, a microservice — holds a sealing key that encrypts ("seals") a machine-generated vault secret, so your server code can open the vault and work on behalf of a user who never logs in and never memorizes a secret.

The at- prefix reads as "sealed at a trusted host." Each package supplies the sealing key from the host's environment — an env var, the OS keychain, or a cloud KMS — never hard-coded, always under your account's own access controls and rotation policy.

Be clear about the trust boundary. Unlike to-* stores and by-* transports — which only ever see ciphertext — an at-* host can decrypt the vault it unseals. This is the one non-zero-knowledge family in noy-db, and it's the point: the safeguard is scope, not secrecy. The sealed secret is stored per vault (at _meta/sealed-secret inside that vault), so a host holding a sealing key can open exactly the vaults sealed under it — nothing else. Offline-first stays the default; online is least-privilege, on infrastructure you own.

Catalog

Start with an on-host provider for local dev and single-instance / single-machine deployments — no cloud dependency, no extra credentials. Move to a cloud KMS provider once you need key rotation, an access-control audit trail (every seal/unseal is an authenticated KMS call, so the cloud's audit log records every vault open for free), or multiple instances sharing one sealing key without sharing a secret file.

On-host

Cloud KMS

Every provider implements the same NoydbSealer contract (id, seal, unseal), so switching backends is a one-line change to sealingKey.

Compare