Which local port was the dashboard on again?
The Apiary runs several services on your machine, each on its own port, and hunting across loopback tabs is nobody's idea of a dashboard. Hive is the front door: one always-on address at 127.0.0.1:3853 that serves the whole thing. Bookmark it once and you are done.
curl -fsSL https://get.theapiary.sh | sh Why one address instead of a port per service?
Because port-hunting is not your job. Hive serves memories, projects, the graphs, sync, logs, ROI, and settings from a single URL, with a live health rail on every page so you always know the state of the fleet.
What do I see if I open it mid-boot?
An honest readiness screen, one bee per service, that dismisses itself the moment the fleet is ready. You never get a broken page or a false first-time-setup screen just because something was still waking up.
A panel says unreachable. Is my data gone?
No. It means that one service is not answering right now; Doctor restarts it and the panel recovers on its own. The rest of the dashboard keeps working the whole time.
Is it exposed to the network?
No. Hive binds to 127.0.0.1 only, so nothing off your machine can reach it, and it passes your session straight through to the services that own your data while storing nothing itself.
How do your engineers see the health of their AI stack without port-hunting?
The Apiary runs several local services per developer, and a status view scattered across loopback ports is a status view nobody checks. Hive is one always-on portal at 127.0.0.1:3853 that serves the entire dashboard and a live health rail, built to be the last thing standing when something else goes down.
Why does a single portal matter operationally?
Because visibility that takes effort gets skipped. Hive puts memories, graphs, sync, logs, ROI, and per-service health behind one address, so an engineer always knows the state of their stack at a glance.
Does it become a new point of failure?
No. Hive is its own service, booted at startup and watched by Doctor, and if a service behind it drops, that panel says so while the rest keeps working and recovers on its own. It was built to survive the exact moment you need a status view.
What is its security surface?
Minimal. It binds to loopback only, so nothing off-device can reach it, and it stores nothing: your session passes straight through to the services that own your data. Sign-in creates your Deeplake credential on your machine, not in the portal.
What does it give an operator that per-service pages don't?
One honest picture. A health rail on every page, a readiness screen on cold boot, and per-service metrics and logs in one place, so triage starts from a single source of truth instead of a tab hunt.
