Beevibe: a self-hosted control plane for teams that run agents on their own laptops
The agent-native OS for companies.
At a glance
- What is it?
- Beevibe is an Apache-2.0 TypeScript stack that puts a shared Postgres-backed workspace behind per-user agent CLIs. The interesting part is the split between the server control plane and the local daemon that actually spawns Claude Code, and the interesting question is whether that split holds up when daemons go offline.
- Who is it for?
- Adopt Beevibe if your team already runs Claude Code or Codex per engineer and you want a shared task, memory and escalation layer without handing your files to a vendor, and if you are willing to operate Postgres, the api, the scheduler and a daemon on every participating laptop. Do not adopt it if you need a hosted product with no local processes, or if your agents must run without an engineer's machine being online.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The coordination gap Beevibe is aimed at
The README states the problem in one line: each person's AI work lives in a private bubble, and no shared intelligence compounds. The target user is a team where several engineers each run their own Claude Code, Cursor or Codex session all day. Individually those sessions are productive. Collectively nothing is retained. The same context gets re-explained, and the same answer gets learned and forgotten by different people.
Beevibe's answer is not a better model or a better prompt. It is a shared surface for the AI side of the team, positioned explicitly against Slack, Notion and Linear, which the README describes as how humans coordinate. The concepts it introduces map onto that: a Workspace holds people, agents, tasks, memory and review; a Task is a unit of team work that can spawn child tasks and move through review; a Mesh is the agent-to-agent layer for asking, negotiating, responding and escalating.
So the audience is narrow but specific: teams that have already standardised on per-engineer CLI agents and now want ownership, handoffs and review to be visible somewhere other than a chat thread. If your team runs agents through a single hosted API with no local CLI, the premise does not apply.
Control plane, memory layer, and the daemon that does the work
The architecture diagram splits the system into four named pieces. @beevibe/api is the control plane, exposing REST, SSE, MCP and a /runtime endpoint plus WSS. Postgres with pgvector holds shared state, the mesh, memory and sessions. beevibe-daemon runs on a user's laptop and spawns the local Claude CLI for every session pinned to that machine. @beevibe/scheduler is a server-side fallback claimant for mesh asks targeting agents whose daemon is offline, and it also runs the orphan reaper for crashed sessions.
The data flow follows the same split. The web dashboard talks to the api over REST and SSE. Agent runs reach the api over MCP tools using HTTPS. The daemon is notified by WebSocket push and claims work over HTTP. If the daemon is not reachable, the scheduler polls Postgres as a fallback claimant.
The design consequence is worth stating plainly: the api never spawns a local CLI in the hosted configuration. The README says this directly for the Railway path, where each user still installs beevibe-daemon to run agent sessions. Your files and your tokens stay on your machine, which is the point of the BYO CLI model. It also means the control plane can only coordinate work that some laptop is willing to execute.
Memory is the part that differs from a task tracker. Each agent has durable core memory blocks plus vector-searchable facts, and the concept table describes agents as having an identity, domain, hierarchy level, memory, API key and preferred runtime. A Runtime is a registered (daemon, CLI) pair, such as a user's local claude, codex or opencode binary.
Getting the stack up: Docker quickstart and Railway
There are two documented paths. The local Docker path brings up Postgres, api, scheduler and web from the repo root, and the README notes that no Node, pnpm or manual migrations are required. The exact commands are:
git clone https://github.com/beevibe-ai/beevibe.git && cd beevibe
ANTHROPIC_API_KEY=sk-ant-… OPENAI_API_KEY=sk-… docker compose -f docker-compose.quickstart.yml up -d --build
Then open http://localhost:3030. The compose file builds the three Node images from infra/railway/, runs migrations as a one-shot, and starts the stack. Shutdown is docker compose -f docker-compose.quickstart.yml down -v.
The Railway path provisions the same four services as a template. After provisioning, the README says to set ANTHROPIC_API_KEY and OPENAI_API_KEY on the api and scheduler services, then point BEEVIBE_CORS_ORIGINS on the api and the NEXT_PUBLIC_BV_API_URL web build argument at the public URLs Railway assigned. Full notes are in DEPLOYMENT.md.
Both paths stop short of a working agent. The README is explicit that the hosted api does not spawn local CLIs, and the local Docker section is truncated mid-sentence at the point where it would explain how to dispatch agent work. That is the first thing to resolve from the repository itself: the daemon installation and runtime registration steps are not in the material available here, so treat the quickstart as covering the server side only.
Where the BYO CLI model breaks down
The strongest constraint is also the selling point. Work is pinned to a machine, so a session can only run while that machine's daemon is reachable. Beevibe acknowledges this and provides the scheduler as a fallback claimant, but the README describes the scheduler as a server-side fallback for mesh asks, not as a general replacement for a missing daemon. If your laptop is closed, the agent that lives on it is not running.
The orphan reaper exists because crashed sessions happen, which tells you the maintainers expect daemons to die mid-run. That is a reasonable assumption for a process on a laptop. It is also a failure mode you inherit: an interrupted spawn leaves state that something has to clean up, and the reaper is that something.
The second constraint is operational surface. Self-hosting here means Postgres with pgvector, three Node services, a scheduler, and a daemon per participating machine. The README frames ownership of those pieces as a feature, and for teams with a reason to keep files and tokens local it is. For a team of five that wants a hosted tool and no infrastructure, this is the wrong shape entirely.
The third is version maturity. The most recent release listed is v0.1.8 from June 2026, with v0.1.7 and v0.1.6 in the weeks before. A 0.1 line moving on a roughly two-to-three week cadence is early software. Nothing in the material states a support policy, a migration guarantee between releases, or how the database schema changes are handled beyond the one-shot migration step in compose.
How this differs from wiring agents into an existing tracker
The obvious alternative is to keep using a human coordination tool and give agents access to it. That is the pattern the README implicitly argues against: Slack, Notion and Linear are how humans coordinate, and Beevibe is meant to be the same surface for the AI side of the team.
The difference in approach is concrete. In a tracker-based setup, an agent is typically a bot account that reads and writes issues, and any memory it has lives in the agent's own prompt or an external store that the tracker knows nothing about. In Beevibe, memory is a first-class column of the system: durable per-agent core memory blocks plus vector-searchable facts in Postgres with pgvector, alongside tasks, ownership and review in the same database.
That matters for the mesh. Agent-to-agent asking only makes sense if the asking agent can find the right specialist and that specialist has bounded domain memory to answer from. The concept table describes agents as having a domain and a hierarchy level, and the mesh as the layer for asking the right teammate, negotiating, responding and escalating. A generic issue tracker gives you assignment and comments; it does not give you a domain-scoped memory that deepens across sessions.
The trade-off is that you now maintain a second coordination system next to the one your humans already use, and the material does not describe any integration with Slack, Notion or Linear. If your team will not look at a second dashboard, the shared-intelligence argument does not get off the ground.
Licence, maintenance and what the 0.1 cadence implies
Beevibe is Apache-2.0, and the README states self-hosting plainly: you own the Postgres database, the Node services, the local daemon processes and the CLI binaries doing the work. Apache-2.0 permits commercial use and modification, and it includes a patent grant. It does not, by itself, settle questions about the licences of the CLIs your daemons spawn, the models behind ANTHROPIC_API_KEY and OPENAI_API_KEY, or the data protection obligations that follow from storing team memory in your own Postgres. Those are separate questions and this is not legal advice.
Maintenance cost is dominated by the daemon fleet rather than the server. The server side is a compose file and a Railway template. The client side is a process on every participating laptop, registered as a Runtime, holding an agent API key, and expected to claim sessions over WebSocket push or HTTP. Every new engineer is another daemon to install, and every laptop replacement is a runtime to re-register. The README does not describe central daemon management, auto-update, or health reporting beyond the claim and push paths.
Upgrades are the open question. The compose file runs migrations as a one-shot, which covers the local path, but the material does not say whether schema changes are reversible, whether old daemons keep working against a newer api, or what the compatibility contract is between the four services. On a 0.1 release line, assume you will be reading release notes before each bump rather than pulling automatically.
Editorial conclusion
Adopt Beevibe if your team already runs Claude Code or Codex per engineer and you want a shared task, memory and escalation layer without handing your files to a vendor, and if you are willing to operate Postgres, the api, the scheduler and a daemon on every participating laptop. Do not adopt it if you need a hosted product with no local processes, or if your agents must run without an engineer's machine being online. Before committing, verify the daemon claim path end to end: start the local Docker stack, register one runtime, and confirm that a session pinned to that machine is claimed and spawned, then kill the daemon mid-session and confirm the scheduler fallback and orphan reaper behave as the architecture diagram claims.
Community notes