✨ Features | 🚀 Deploy | ⚙️ Configuration | 📖 Docs | 💬 Discussions
Watch every coding agent on every machine — and step in the moment one needs you.
|
OpenShift Developer Sandbox, no credit card. |
One container, one port, one volume. |
- Catch the moment an agent needs you. Permission prompts, idle sessions, finished runs — paged to you instead of buried across terminals you forgot to check.
- One view of the whole fleet. Every session, every machine — model, branch, context, PR — in a single glance.
- Unblock from anywhere. Open the dashboard on your phone, attach to the session's terminal, type the answer, walk away.
Your data stays on your machines. Uninstall is one command.
I run my fleet on this every day across 3 machines. — Marc
- Browser terminal — attach to any session from any device, including your phone.
- Push notifications that survive a closed tab — a service worker keeps you reachable after you've moved on.
- Workflow templates — Implement Issue and Review PR prime sessions with opinionated, scope-first prompts (TDD, root-cause, multi-persona review) instead of spawning blank shells.
- Worktree-aware session spawning from the browser — start a session on a fresh branch and a fresh worktree in one click.
- Real-time multi-machine dashboard — model, context, cost, branch, PR status per session.
- Status detection — working / idle / awaiting permission, surfaced as the session state.
- Pluggable agents — Claude Code and OpenCode today; plugin SDK in Go for the rest.
- Multi-deploy — native binary, Docker, Helm, OpenShift Sandbox, Hugging Face Spaces.
- Auth modes — PSK, password, OIDC, OAuth Proxy, Hugging Face identity.
- Native Linux / macOS / Windows binaries (amd64 + arm64).
Note
Early access — binaries, container image, and Helm chart are available now; source will be published after this validation phase. Currently supports Claude Code and OpenCode (more agents planned via the plugin SDK). Feedback via issues and discussions is the whole point of this phase — please open one.
Support: Marc responds personally to Discussions within 24 hours. Stuck on install? @-mention @manusa in the thread for a faster reply.
Pick a deployment method and follow the steps — the built-in setup guide will walk you through connecting your first agent.
| Method | Best for |
|---|---|
| OpenShift Developer Sandbox | Free cloud dashboard, no credit card |
| Docker (local) | The fastest way to try the dashboard on your own machine |
| Any Kubernetes cluster | Your own cluster with Helm |
| Hugging Face Spaces | Free cloud dashboard gated by your Hugging Face account |
Power users can also grab a native binary directly — Linux, macOS, or Windows.
The Developer Sandbox is free and available to anyone with a Red Hat account. The same recipe works on any OpenShift cluster.
# 1. Set the agent token
# The token authenticates agents to the dashboard. Browser login uses
# your OpenShift / Red Hat account via the OAuth Proxy sidecar — no
# password to manage. Only usernames listed in --set allowedUsers can
# sign in; the snippet below allows your current OpenShift user.
export TOKEN=$(openssl rand -hex 32)
# 2. Install (into your current namespace — the sandbox assigns one for you)
helm install ai-beacon \
oci://ghcr.io/manusa/charts/ai-beacon \
--version 0.0.0-snapshot \
--set openshift=true \
--set oauthProxy.enabled=true \
--set persistence.enabled=false \
--set auth.token="$TOKEN" \
--set allowedUsers="{$(oc whoami)}"
# 3. Get the dashboard URL
oc get route ai-beacon -o jsonpath='https://{.spec.host}'Open the dashboard URL in your browser. You'll be redirected to OpenShift to log in with your Red Hat account, then asked to authorize the dashboard.
Once inside, click the rocket icon in the top bar to open the setup guide:
The guide walks you through downloading the CLI and connecting your first agent. Then head to Agent configuration for optional tuning.
Note
--version 0.0.0-snapshot is a rolling pre-release alias that tracks the latest build.
It is required until a stable release is published.
The fastest way to try the dashboard on your own machine. No cluster, no signup.
Don't have Docker yet? Install it from docs.docker.com/get-started. If you prefer Podman, replace
dockerwithpodmanin every command below — the recipe is identical.
docker volume create ai-beacon
docker run --pull=always \
-e AI_BEACON_AUTH_PASSWORD=demo \
-p 8080:8080 \
-v ai-beacon:/data \
ghcr.io/manusa/ai-beacon:latestOpen http://localhost:8080 and log in with password demo.
The dashboard will be empty until you connect an agent — click the rocket icon in the top bar to open the setup guide:
Then head to Agent configuration for optional tuning.
Important
Mount /data to a persistent volume (named volume above, or a bind mount). The agent auth token lives there; without a volume, every container restart regenerates it and silently invalidates the token baked into your installed agent hooks — sessions stop appearing on the dashboard until you re-run ai-beacon install with the new token.
To inspect the auto-generated agent token from a running container:
docker exec $(docker ps -qf ancestor=ghcr.io/manusa/ai-beacon) cat /data/tokenexport TOKEN=$(openssl rand -hex 32)
export PASSWORD=changeme
helm install ai-beacon \
oci://ghcr.io/manusa/charts/ai-beacon \
--version 0.0.0-snapshot \
--set ingress.host=ai-beacon.example.com \
--set auth.token="$TOKEN" \
--set auth.password="$PASSWORD" \
-n ai-beacon --create-namespaceOn clusters with persistent storage, you can omit auth.token and auth.password — credentials are auto-generated and persisted to the volume. Retrieve them with:
kubectl exec -n ai-beacon deploy/ai-beacon -- cat /data/password
kubectl exec -n ai-beacon deploy/ai-beacon -- cat /data/tokenSee Agent configuration for optional tuning.
Hugging Face's free CPU tier accepts arbitrary Docker images and projects the signed-in HF user's identity into the container via OAuth/OIDC — so the dashboard's "who is allowed in" question is answered by your existing Hugging Face account, with no IdP to configure and no password to manage.
The full recipe lives in huggingface-space/: push that directory to a fresh Space, set two secrets, restart the Space. The auth side is covered in docs/auth.md.
AI Beacon works out of the box, but most features require these tools on the machines running your agents:
| Tool | What it unlocks |
|---|---|
git |
Current branch display, worktree management |
gh (authenticated) |
PR status and checks on session cards, review and merge PRs from the dashboard |
Without them the dashboard still tracks every session's model, context usage, cost, and duration.
The setup guide covers installing the CLI and connecting to the server. These additional environment variables are optional but useful:
| Variable | Purpose | Default |
|---|---|---|
AI_BEACON_PROJECTS_DIR |
Base directories for your repositories — enables spawning new sessions and worktree workflows from the dashboard. Accepts one path or a list joined by the OS path separator (: on Unix, ; on Windows) |
(disabled) |
AI_BEACON_DEVICE_NAME |
Friendly name shown in the dashboard for this machine | hostname |
AI_BEACON_JIRA_URL |
Jira instance base URL — enables pasting a Jira ticket into the Implement Issue workflow. Pair with AI_BEACON_JIRA_TOKEN (plus AI_BEACON_JIRA_EMAIL on Atlassian Cloud); generic JIRA_URL/JIRA_USER/JIRA_TOKEN are read as fallbacks. See Jira tickets. |
(disabled) |
Set them in your shell profile (e.g. ~/.zshrc) so they apply to every session:
export AI_BEACON_PROJECTS_DIR=~/projects
export AI_BEACON_DEVICE_NAME=macbookEvery other knob — server flags, Helm values, the config.toml file, data-directory layout — lives in docs/configuration.md.
For everything beyond the initial deploy and first session — multi-machine setup, auth modes (OIDC, proxy-header), GitHub integration, workflow prompts, the full configuration surface, and troubleshooting — see docs/.
