One brain for your whole organisation, on a server we run. Every machine and every person you let in reads and writes it. It is the same ns-brain binary and the same commands as the local edition: a project is attached to the server instead of to a file. Start with setup. Read the memory model once, because it explains every time the brain says no. Keep the CLI reference open.
Sign up, name the organisation and you are its owner. Each machine signs in with ns-brain hive login: it prints a code and somebody with admin approves it. The credential is kept outside every project, readable only by you.
ns-brain init --hive <url> for a project with no brain yet. ns-brain hive join for one with a local brain: a dry run first, then --apply copies it up. hive leave --apply brings it back to a local brain.
Projects are nodes in a tree you define and a grant is inherited downward. Five roles, from reader to owner. Writing a guardrail or an org axiom is a separate authority from rank. Every memory carries who stored it.
Read →Types, how fast each one fades, how results are ranked, scopes, confidence and trust, corrections, commit stamps and review dates. The server runs the same kernel as the local edition, so this is the one page worth reading top to bottom.
Read →The commands you type are the ones you would type on a local brain. Once a project is attached they go to the server. The hive subcommands for signing in, people and compliance are on the setup page and in ns-brain hive help.
What each agent supports (session start, every message, session end and MCP), tested on a clean machine against that agent's own release. The hooks are the same on Hive, so the brief arrives from the server before the first turn.
Read →For an agent that cannot run shell commands. MCP is served by ns-brain on your own machine and reaches the brain through the same credential. There is no hosted MCP endpoint yet.
Every route the server serves, what credential it takes and what it answers. The CLI is the supported client. We publish the API because you can only leave an API you can read, including the export every refusal points you at.
Read →A data key per organisation, a master key kept apart and reads logged as well as writes. We hold the keys, so we can decrypt it. The page says what stops us and what to run if you need an arrangement where we cannot.
Read →A brain encrypted on your own devices, chosen per brain. The server holds ciphertext and metadata. Search runs on each device and matches words only. Lose the paper and every device and nobody can get it back, us included.
Read →What is due and when, numbers that only make sense tracked over time and what the brain knows about each person. Tasks live on the server with the project, so every machine sees the same list.
Read →Each project reads its own node. The server enforces that, so a client cannot ask its way past it. Notes between projects, org axioms and published lessons cross the boundary. Nothing that arrives this way gets to give orders.
Read →The brief did not show up. Recall finds nothing. The server cannot be reached. Start with hive status and hive queue, then doctor, map, review and how to read a refusal.
Each machine signs in once and each project is attached once. After that the work is the CLI you already know. The rest of these pages are for when somebody joins, an agent needs MCP or the server cannot be reached.
| Situation | What you run | Page |
|---|---|---|
| Your first machine | hive login, approved by an admin | Setup |
| A project that already has a local brain | hive join, then hive join --apply | Setup |
| A new project on a machine already signed in | init --hive <url> | Setup |
| A colleague joins | They run hive login. You approve with hive approve or the dashboard | Setup |
| An agent that cannot run shell commands | MCP over stdio, on your own machine | MCP |
| The server cannot be reached | Writes queue on their own. hive queue shows them and hive flush sends them | Setup |
| A security review | Nothing. Read the page | Security |
| Leaving Hive | hive leave --apply, back to a local brain you own | Setup |
ns-brain init writes both into the brain directory, brain/, on an attached project too, so your agent already has them without downloading anything. It does not edit your CLAUDE.md.
HOWTO.md is the how: which command to use, what each flag changes and what the output looks like. BEST-PRACTICES.md is the when: what is worth saving, what the code or git already says (so saving it is noise) and how to write a title you can still find months later. Both are the same on either edition.
If an agent landed here because somebody told it join https://hive.fightclub.pro, the steps are in llms.txt, served by the brain itself. It does not need the HTML.