queen FAQ

Quick answers to the questions people ask first about queen. It's coming soon and not available yet; these answers describe the design.

#What is queen for?

queen is the cloud control plane for when the apiary stack outgrows a single machine. On one machine, everything runs locally and there's nothing to coordinate. Once you have a team, or an orchestrator spinning up throwaway workers, someone needs to answer which agents are alive, who can add a new one, how spend rolls up across the org, and what happens fast when a device is lost. That's the job queen is built to do.

#Does the cloud see our memory?

No. This is the one rule queen is built never to break. The control plane holds coordination state and coarse usage facts only, things like liveness, identity, enrollment records, and usage numbers for ROI. It never holds memory content, prompts, completions, session text, tool-call payloads, file paths, repo names, or plaintext credentials. Where a credential has to be referenced at all, only encrypted ciphertext is stored, and the cloud can't decrypt it in the default mode. There's no column in the system that could hold your session text.

#Who actually holds our memory credential?

Your own long-lived orchestrator, not the cloud. This is the orchestrator-custodian model: a durable machine inside your own trust domain links Deeplake once and keeps the private key locally. queen's cloud side coordinates identity and stores only encrypted blobs it cannot open. Full detail is in how queen works.

#How do we add or remove devices?

Adding one: mint a short-lived, single-use join token on a machine that's already trusted, then redeem it on the new machine. No browser opens on the server, no credential gets pasted into a config file, and no key is shared between machines. One heartbeat later, the new machine shows up on the fleet dashboard.

Removing one: revoke the device's identity in queen, and rotate the shared memory credential separately. Those are two honest, separate steps, one control-plane action and one data-plane action. Because every agent has its own identity, revoking one only cuts off that one; the rest of the fleet keeps running.

#What happens if the signing authority goes down?

The fleet doesn't stop. Agents can't receive new commands while the authority is unreachable, but they keep doing local work and keep sending heartbeats. queen is built to degrade agents to autonomous, never to dead; the authority is only needed to issue new commands, not to keep workers running.

#Can queen run offline or air-gapped?

No, by design. Binding to a cloud deployment is a required step, tied to license enforcement. There's a bounded grace window for a short, transient outage of the authority, but beyond that, it fails closed with a clear reason rather than failing silently.

#Does queen watch our desktop apps?

Not in the first version. Observation is limited to command-line and model-gateway traffic, and only coarse facts, not content. Watching desktop apps would mean installing a certificate authority on every machine to intercept their traffic, which is exactly the kind of capability queen is built to avoid needing. It's deliberately out of scope for now, not an oversight.

#Is queen available yet?

No. It's in the specification stage: the architecture is decided and written, but there's nothing to install yet. What you can do today is run the local apiary stack, curl -fsSL https://get.theapiary.sh | sh, on every machine you expect to fleet later. Those machines are exactly what queen will enroll and manage once its cloud layer ships. See getting started with queen for the detail.