Deployment and operations, answered in full.

Token Observe needs one Node.js 24 process, or the published container image, and one configured database — normally a single SQLite file in WAL mode — holding the entire persistent state. There is no second datastore, cache tier, object store or message broker, so backing up that one file backs up the durable state. Terminate TLS in front of it: Token Observe speaks plain HTTP behind your proxy and manages no certificates, and at rest the database is encrypted by whatever your volume or host provides rather than by the product. Your reverse proxy must not buffer responses, or server-sent event streaming breaks; it must preserve the Authorization and x-api-key headers, set the forwarded headers, and allow a read timeout longer than your longest expected model response. The reference Compose file publishes on loopback rather than every interface, deliberately: the dashboard, the API and an unauthenticated Prometheus endpoint carrying agent identifiers and month-to-date spend share that listener.

Getting a first agent governed by Token Observe takes about an hour, of which roughly twenty minutes are mechanical: install, boot, run the quickstart, mint a key, change one base URL, watch the first trace appear. The two steps that take real time are judgements rather than commands — registering the agent, which means deciding who owns it and what it is for, and promoting a policy to enforce, which means deciding which rule you are willing to have block production traffic at three in the morning. That second one is why the honest answer is an hour rather than four minutes. The recommended order is to start every policy in shadow mode so the first day produces findings instead of outages, then promote to enforce once you know the false-positive rate. The install reports its own configuration through a readiness endpoint computed from live state rather than a setup flag, so it goes red again the day someone rotates a provider credential out of the environment.

No. Token Observe supports exactly one active process on one node in this release, whichever store is configured, and there is no replica, no clustering and no vendor-operated uptime SLA. SQLite is single-writer by design at this scale; under sustained heavy write load the bottleneck is trace-event insertion rather than the governance decision, and two instances must never point at one SQLite file. PostgreSQL is implemented and exercised in CI against a dual-backend contract, but a passing CI run proves adapter compatibility, not a production deployment, multi-replica safety, point-in-time recovery or a timed restore — the onboarding technical-readiness check deliberately keeps reporting not ready while a database URL is set. Several controls are also process-local: the login throttle, connector token buckets, identity-provider transactions, provider circuit state and upstream MCP sessions. Multiplying processes would multiply the throttle allowance. Keep workloads whose outage would harm customers outside this release.

Token Observe’s whole persistent state is one SQLite file, so back it up like evidence rather than like a cache. The shipped command takes a consistent snapshot against a live database, then reopens the artifact, runs an integrity check, walks every audit row and keyed checkpoint, captures that artifact’s exact head, and fsyncs the file and its manifest before publishing them; copying a live WAL database instead produces a plausible stale one. Record the four values the backup prints — sequence, audit hash, file digest and snapshot-descriptor digest — somewhere this deployment does not control, because that external tuple is what a restore is checked against. A restore also needs the ordered audit key ring injected, not just the file. Two limits stated plainly: this is full-snapshot recovery and not point-in-time recovery, and there is no scheduled backup job, retention enforcement or freshness alarm — the three-copy policy is yours to run and monitor.

Token Observe’s migrations are additive and backward-compatible, so you deploy the new code first and contract in a later release, and /readyz reports unready until migrations have applied — use it as the gate so traffic never reaches a half-migrated process. An ordinary one-release rollback works while no effect-required tool pin has ever been activated. After activation it does not, and the reason is specific rather than cautious: an older binary does not understand the effect state machine and could dispatch that tool without it. The documented emergency path is a drained maintenance window — quarantine every effect-required pin using its already-reviewed descriptor hash, verify the catalogue reports each one quarantined, stop every process, then deploy the older image, keeping the pins quarantined until the fleet is effect-aware again. Rolling back two releases is not tested. If you cannot complete and verify that ceremony, preserve the database and escalate instead.

Token Observe offers no capacity commitment for a single deployment, because the measurement that would justify one has not been run on partner-shaped data, and publishing a figure before that would be a guess wearing a number. The documented pilot envelope is roughly five to fifty API-key agents owned by one platform team, one or two model providers and a bounded set of pinned MCP tools. The only published performance figure is a 30-second laboratory baseline against a mock upstream on a laptop, which measures inline governance work rather than end-user response time, and the source explicitly refuses to let it become a concurrency limit. What the process does have is an admission ceiling: in-flight requests default to 256, and beyond it new work receives 503 ACP_OVERLOADED with a Retry-After while probes stay reachable. Storage grew at roughly 3.1 KB per completed request under that same laboratory mix.