Skip to content
hyperbeamDocs
Get started

Introduction

What Hyperbeam is, who it is for, and how it is different from running an agent in your own terminal.

Hyperbeam is a self-hosted platform where a team’s coding agents work in the open.

Today most agent work happens in someone’s terminal and stays invisible until a pull request appears. Hyperbeam moves that work one level up: anyone on the team can describe an outcome, an agent picks it up in its own sandbox, and everyone can watch the scoping and the building as it happens.

What you get

  • A shared board. Workstreams move from scoping to building to review. Each shows the agents on it, what they are doing right now, and the pull requests they produced. See The board and workstreams.
  • Any harness. Claude Code, Codex, Gemini CLI, OpenCode, or anything else that speaks the Agent Client Protocol. Bring a team API key or your own credential. See Harnesses and models.
  • Permissions that belong to people. An agent can do only what the person who started it may: GitHub or GitLab, the web, and every connected service, per repository. See People and permissions.
  • Agents never hold your credentials. GitHub, GitLab and connected services such as Linear, Notion, Slack, Datadog, Sentry or your own MCP servers are reached through Hyperbeam’s tool gateway and git proxy, which check every request and record it. See Security model.
  • From Slack and Discord. Mention the bot to start an agent, reply in the thread to direct it, and answer its questions with a button. Each person acts as their own Hyperbeam account. See Slack and Discord.
  • Agents that ask. An agent asks when a decision is yours, and you are told when one of yours asks, finishes or fails. See Notifications.
  • Your toolchains. Agents run in an image with your project’s compilers and package managers, whichever harness they use. See Environments.
  • A conductor. One agent that scopes a request, starts worker agents across repositories, and is told when each reports back. See Conductors.
  • Skills, workflows and team notes. What your team teaches its agents, kept in one place and shared by every session. See Skills and team notes and Workflows.

Who it is for

Teams that already use coding agents and want that work to be visible, shared and governed: engineering teams that want to see what agents are doing across repositories, and people who never open a terminal but can describe what they need built or investigated.

How it fits together

 Browser / CLI / Slack / Discord
      │  REST + server-sent events (chat apps: the server dials out)
┌─────▼────────────────── hyperbeam-server ────────────────────────┐
│ API · teams and permissions · session manager · event log      │
│ tool gateway (MCP) · git proxy · egress allowlist proxy        │
└─────┬──────────────────────────────────┬───────────────────────┘
      │ Postgres (all state)             │ one pod per live session
┌─────▼──────────────── agent sandbox ───────────────────────────┐
│ hyperbeam-runner ⇄ ACP over stdio ⇄ harness (Claude Code, …)     │
│ may reach: the control plane. Nothing else, except through it. │
└────────────────────────────────────────────────────────────────┘

The control plane (hyperbeam-server) holds all state in Postgres, serves the web UI and API, and is the only way out of a sandbox. Each live agent session gets its own sandbox: a process on your laptop for development, or a locked-down pod on Kubernetes. Inside it, the runner drives the harness over ACP and streams everything it does back to the control plane.

Next steps

Edit this page
Esc

Type to search pages and sections.