queen docs

queen is the cloud control plane for running the apiary across many machines. it's on the roadmap, not shipped yet. read what it will do and how to get ready.

queen is the coming-soon cloud control plane for the apiary. it will coordinate fleet presence, per-agent identity, signed commands, and hosted ROI reporting across many machines, while custody of your memory credential stays with your own orchestrator, never the cloud.

queen is coming soon. It is not available yet. This page describes what it is being built to do, so you know what to expect and how to get ready with the tools that are available today.

#What is queen?

The apiary is simple on one machine: honeycomb, nectar, doctor, and hive all run behind one local portal, and everything stays on your own loopback. That stops being simple the moment the stack spreads across more than one machine, whether that's a couple of laptops on a small team or an orchestrator spinning up throwaway workers by the dozen.

queen is being built as the cloud control plane for exactly that moment. It's the piece that answers the questions a single machine can't: which agents are alive right now, who is allowed to add a new machine to the fleet, how an admin sees spend across a whole team without remoting into anyone's laptop, and what happens fast when a device is lost or someone leaves.

#What it will do

  • Fleet presence. A read-only dashboard built from heartbeats, so you can see which agents are alive across every machine in your fleet.
  • Per-agent identity and enrollment. Every agent, even a throwaway sub-agent that lives for minutes, gets its own identity that can be revoked on its own. No shared forever-key that takes down the whole fleet if it leaks.
  • A signed command channel. One authority signs commands, agents verify them, and if that authority goes down, agents keep doing local work instead of stalling.
  • Hosted ROI reporting. Spend and usage rolled up per org, per team, and per user, so the numbers you see are measured, not guessed.

#The rule it won't break

queen coordinates identity, presence, and encrypted blobs it cannot decrypt. It never reads your memory content. The credential that unlocks your team's shared memory in Deeplake stays in the custody of your own long-lived orchestrator, not the cloud. That split, orchestrator holds the key, queen coordinates around it, is the whole trust model, and it's covered in full in how queen works.

#Where it fits

Observation ships before control. The local stack, honeycomb for memory, nectar for understanding, doctor for the local watchdog, hive for the local portal, installs today and runs entirely on your own machine. queen's cloud layer is what will eventually watch and steer the fleet those machines form. Running the local stack now is how your machines become the fleet queen will manage later.

#Where to start

  • Getting started with queen: there's nothing to install yet, so this covers how to get your machines ready.
  • How queen works: presence, identity, signed commands, ROI, and the custody model in detail.
  • queen FAQ: quick answers to the questions people ask first.

#Common questions

Is queen available right now? No. It's in design and specification. This section of the docs describes the plan so early adopters and admins know what's coming and can get their machines ready.

What do I install today? The local apiary stack: curl -fsSL https://get.theapiary.sh | sh. That's honeycomb, nectar, doctor, and hive. queen layers on top of that stack once it ships.

Will queen ever read our memory or prompts? No. By design, the control plane holds coordination state and coarse usage facts only. It never holds memory content, prompts, session text, or plaintext credentials.