# Scale & the edge seekrit is globally distributed by construction. Because encryption and decryption are the client's job, the server never holds anything but ciphertext — and ciphertext is the easiest thing in the world to move closer to whoever is asking for it. There is no cluster for you to size and no secret material to replicate. ## Runs on Cloudflare's edge The API is a single [Cloudflare Worker](/docs/concepts/architecture) served from Cloudflare's global network, backed by a managed Postgres database reached over pooled, kept-warm connections (Cloudflare Hyperdrive). Requests are handled close to wherever they originate — a laptop in Berlin, a CI runner in `us-east`, an agent sandbox anywhere — without you provisioning or operating a thing. The database itself lives in one region, which matters less than it sounds: the route that runs on every workload boot is answered from the edge cache described below, and never reaches it. ## The hot path: resolving secrets Every running workload — a container, a CI job, an AI agent — calls `GET /v1/resolve` on startup to fetch the secrets for its environment. This is by far the busiest route: one organization can drive tens of thousands of resolves a day. seekrit is built to serve it cheaply and correctly. The route is split across two roles inside the same Worker: - A **gateway** that always runs: it authenticates the caller, decides which org and environment are in play, and meters the read for usage and billing. - A **resolver** that owns the cache: it does the database work — gathering the encrypted secret layers and the caller's individually-wrapped data key — and caches the result at the edge. ## Caching that stays zero-knowledge Resolved responses are cached **at the edge**, so repeat boots of the same workload are served without touching the database. Two properties keep this safe: - **Only ciphertext is cached.** Encrypted secret values and already-wrapped data keys — never plaintext. The zero-knowledge invariant is unchanged: a cache, like the database, holds nothing readable. - **The cache key includes the caller's identity.** A caller's principal, org, environment, and any overrides are folded into the cache key. Two principals never share an entry, and no one can be served another principal's wrapped key. Identity is verified on every request by the gateway, cache hit or miss — it is never bypassed by a warm cache. > **Note:** A wrapped data key is only useful to the principal it was wrapped for — decrypting it still requires that principal's private key, which never leaves their machine. Edge caching moves ciphertext closer to the caller; it never moves the ability to read it. ## Staying correct: tag-scoped invalidation Speed is worthless if it serves stale secrets. Each cached response is tagged with every environment it read (an app environment plus any composed groups). Any change that could alter the result — writing or rotating a secret, granting or revoking a key, changing composition, deleting an environment — purges exactly those tags. Unaffected environments keep their warm caches; the ones that changed are refreshed on the next read. A short backstop lifetime bounds staleness if a purge is ever missed. ## Metering, not per-read audit Mutations are always [audited](/docs/concepts/security) synchronously to an append-only trail. Successful resolves are the deliberate exception: at tens of thousands a day they are **metered** to an analytics pipeline (fire-and-forget, sampled) for usage and billing rather than written to the durable audit log. Metadata only — never ciphertext, never plaintext. Denied resolves *are* audited durably, because those are the security-significant events. ## The bottom line The same design decision that makes seekrit private — encryption belongs to the client — is what lets it scale. A ciphertext-only server can cache safely at the edge — right next to your workloads, with nothing readable in the copy — and grows from a single developer to a fleet of agents with no infrastructure on your side.