@legioncodeinc/hive
Advanced tools
The front door to your agents' shared brain.
One URL, always on, and every daemon in the Apiary is standing behind it.
A Legion Code Inc. × Activeloop collaboration.
The Apiary runs four daemons on your machine: Honeycomb doing the memory work, Nectar mapping your sources, Doctor watching all of them, and each one holding its own port. Great architecture. Miserable to look at. Which port was the dashboard again? Is my memory daemon even up, or did it die overnight? Why is my browser juggling origins and tokens for three separate loopback services just to render one status page?
Hive is the answer to all of it. One always-on portal daemon at 127.0.0.1:3853. It boots with your device, renders the moment its socket binds, and serves the entire Apiary dashboard from a single origin. When a workload daemon has not answered yet, its panel says "starting," never a broken page. That failure mode is the whole reason Hive exists: the old dashboard lived inside Honeycomb, so exactly when you needed a status surface most was exactly when it went dark.
New here? One command and you're on a dashboard. Jump to Install. · Want the docs? Everything lives at theapiary.sh.
🛹 For AI Augmented DevsOne URL for the whole stack. You bookmark |
🏢 For Enterprise TeamsOne origin, one boundary. The browser never sees a workload daemon's port or holds a credential for it; Hive's server proxies every request over loopback and passes auth headers straight through without storing a thing. Nothing sensitive lives in the browser, and no daemon owes the world a CORS allowance. |
Plenty of tools bolt a status page onto a daemon. Hive is built the other way around: the portal is the product, and four deliberate decisions make it hold up.
/api/* and /setup/* request, fetches it over loopback, and streams it back. No CORS on any workload daemon, no daemon ports handed to a browser, loopback trust enforced on the server with redirect pinning.
/api/* and /setup/* to the owning daemon: Honeycomb (:3850), Nectar (:3854), each resolved from Doctor's registry./api/fleet-status reads the supervisor's status page server-side, so the portal shows honest per-fleet health instead of guessing from failed fetches.:3853 with /health, a PID/lock single-instance guard, and OS service units (launchd, systemd, schtasks) that restart it on crash and start it on boot.
Hive doesn't install alone; it comes up as part of the Apiary stack. One line, and the installer handles Node, npm, the daemons, and the watchdog.
# macOS / Linux
curl -fsSL https://get.theapiary.sh | sh
# Windows (PowerShell)
irm https://get.theapiary.sh/install.ps1 | iex
That single line installs the whole Apiary: Honeycomb, Nectar, Doctor, and Hive, which comes up at 127.0.0.1:3853 and becomes the one address you ever need to remember. The terminal is just a progress log; the portal is the product.
git clone https://github.com/legioncodeinc/hive.git
cd hive
npm install
npm run build # tsc + esbuild → dist/cli.js
node dist/cli.js daemon # foreground development process, binds :3853
npm run typecheck # tsc --noEmit
npm test # vitest run
The portal aggregates its data from the other Apiary daemons over loopback, so a source build of Hive alone gets you the shell and fleet status; the full dashboard lights up when Honeycomb and friends are running.
Open http://127.0.0.1:3853 and the shell renders immediately, even on a cold boot. While the fleet is still waking up you get a readiness splash with per-daemon health rows instead of a false "first time setup" screen. Once the fleet is ready, the full portal takes over: the memory pages, the graph, sync, and ROI views migrated from Honeycomb, plus fleet status pulled from Doctor. Every page hydrates through the same-origin wire, proxied server-side to whichever daemon owns the data.
The hive binary now follows the shared Apiary operational contract. Bare invocation and --help show Hive's ASCII identity, HIVE, the package version, grouped commands, and the exact credit Legion Code Inc. x Activeloop.
hive start # start the already-installed OS service
hive stop # stop the installed OS service
hive restart # stop, start, and wait for Hive health
hive install # onboard Hive: reconcile the service and Doctor registration
hive uninstall # full product removal; only Hive-owned state is eligible
hive service-install # install or reconcile only the OS service definition
hive service-uninstall # remove only the OS service; preserve state and registration
hive update # update through Hive's approved package channel and verify health
hive status # show service, process, health, registration, version, and paths
hive register # idempotently upsert Hive in Doctor's registry
hive logs # tail only Hive's configured service logs
hive telemetry # read-only telemetry state and delivery-health summary
hive daemon # run Hive in the foreground on 127.0.0.1:3853
hive --help # branded, grouped command reference
hive --version # exactly: hive v<package-version>
start no longer means "run the foreground process." It controls the installed service and fails with guidance to run hive service-install when no service exists. Use hive daemon for foreground development, containers, or direct process supervision.
install and service-install intentionally own different transactions. install performs Hive onboarding and Doctor registration; service-install touches only the OS service definition. Likewise, service-uninstall preserves Hive state and Doctor registration, while uninstall performs the full product-removal transaction. The old install-service and uninstall-service spellings remain temporary deprecated aliases, but new scripts and documentation must use service-install and service-uninstall.
Every baseline operational command accepts --json. JSON mode emits one stable object with product, command, ok, and message (plus command-specific details), one trailing newline, and no banner, color, credit, prompt, or extra prose. Success and already-satisfied idempotent operations exit 0; service/runtime failures exit 1; unknown commands and usage errors exit 2. Automation should branch on the exit code and JSON fields rather than on a human sentence or stream.
logs is hard-bound to Hive's own service identity and log destination. It defaults to the last 100 lines plus follow mode and supports --lines <n>, --no-follow, and --since <duration-or-timestamp>. status is a bounded snapshot and does not start Hive. Bare telemetry is read-only, reports the controlling opt-out setting and available delivery state, and never prints credentials.
For the full migration and automation checklist, see PRD-003 CLI migration.
Two behaviors worth knowing:
uninstall is surgical and honest. It stops the daemon, removes the service unit (current com.legioncode.hive and legacy thehive labels), deletes Hive's entry from Doctor's registry without touching anyone else's, and removes ~/.apiary/hive, nothing more. Already gone? It exits 0 and says so. For a full-machine wipe, see doctor purge or the one-command uninstall at get.theapiary.sh.
# One address. No port hunting, no tab juggling.
open http://127.0.0.1:3853
# Honeycomb up, Nectar up, Doctor watching, memories flowing.
# You just checked four daemons without remembering a single port number.
Kill a workload daemon mid-session and the dashboard doesn't blink: that daemon's panels go "unreachable," everything else keeps rendering, and the page recovers on its own when Doctor brings the daemon back. That's the moment this thing earns its keep.
The browser talks to exactly one origin. Hive's server does the reaching around, over loopback, with the trust checks on its side of the line.
flowchart TD
browser["Browser"] -->|"same-origin /api/*, /setup/*"| hive["Hive :3853<br/>portal + BFF proxy"]
hive -->|"loopback proxy"| comb["Honeycomb :3850<br/>memory workload"]
hive -->|"loopback proxy"| nectar["Nectar :3854<br/>hive graph workload"]
hive -->|"fleet status"| doctor["Doctor :3852<br/>supervisor status page"]
The browser never talks to the back daemons directly. Hive resolves each request's owner from Doctor's registry, guards every resolved base as loopback-only, pins redirects so a daemon can't bounce a proxied fetch off the machine, and forwards your session headers verbatim without keeping any credential of its own.
Here's the thing about a stack of loopback daemons: individually they're clean, collectively they're a chore. Four processes means four ports, and four ports means the knowledge of your own tooling lives in your head instead of in the product. Every "wait, which one was 3854" is a small tax, and small taxes compound.
One front door collapses that. Your credentials cross exactly one boundary, enforced by a server you control, instead of being sprayed across browser tabs that each talk to a different origin. Your bookmark bar holds one entry. When something breaks at 2 a.m., you don't run a mental port scan; you open the one page and the sick daemon is the red row.
And there's a quieter payoff: the stack starts feeling like one product. Honeycomb, Nectar, and Doctor stay sharply separated where it counts, in process boundaries and data ownership, while you experience them as a single coherent surface. Separation of concerns for the machine, one front door for the human. That's the trade Hive makes, and it's the right one.
Straight talk: Hive ships two surfaces, and that's it for now.
http://127.0.0.1:3853. This is the product.GET /health for cheap liveness (status, uptime, version) and GET /api/fleet-status for fleet health, plus the proxied /api/* and /setup/* surfaces of the daemons behind it.No MCP server, no SDK, and none pretending. The workload daemons own those surfaces; Hive owns the door.
Hive is production ready (v0.5.x) and fully tested in live scenarios. The whole PRD program has shipped: the portal daemon, the migrated dashboard, the server-side BFF proxy, the OS service units and registry wiring, the portal gate, the fleet readiness surface, the Hive Graph page, and the onboarding installer. We document what's shipped; the roadmap and idea board for what comes next live at ideas.theapiary.sh.
npm install
npm run build # tsc + esbuild → dist/cli.js
npm run typecheck # tsc --noEmit
npm test # vitest run
Node >= 22, TypeScript, Hono on the server, React on the dashboard. The proxy surface (header hygiene, redirect pinning, streaming) carries its own test coverage; keep it that way.
Hive is licensed under the GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later).
Use it commercially or privately, free of charge. In return: keep the copyright and license notices intact, and if you modify it, your changes ship under the same AGPL license with source available. The "Affero" part is the point: run a modified version as a network service and you owe its source to the users who interact with it. No locking a fork behind a SaaS wall.
© 2026 Legion Code Inc.
Built by Legion Code Inc · Powered by Activeloop Deeplake · theapiary.sh
I am Legion. We are Legion.
#vibewithlegion
FAQs
Hive portal daemon
The npm package @legioncodeinc/hive receives a total of 0 weekly downloads. As such, @legioncodeinc/hive popularity was classified as not popular.
We found that @legioncodeinc/hive demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Product
Socket Threat Intel now shows which malware campaigns were blocked or detected in your organization, with links to scans and Firewall events.
Security News
Fixes for eMudhra and Brotli are out. Getting them everywhere they’re needed means tracking down bundled libraries, runtimes, and certificate stores.
Threat Research
/Security News
Socket uncovered secret-stealing workflows that ran in LiteLLM’s GitHub repository 11 days before the supply chain attack on PyPI and Docker.