RelayHall v1.0.0-beta.102: the second public beta

The second public beta of RelayHall is out: v1.0.0-beta.102. It follows the first public beta of 8 September. It adds a permission and ownership model for Groups, change requests, one-line harness connections, an Action Center, a knowledge search console, a plugin host with settings and a much wider MCP and CLI surface. It also makes a first install work from start to finish: setup.sh now asks for your public address and generates the keys the board needs.

Two things to know before you start. This release is for fresh installs. Install it into an empty database. Upgrading an existing install, including the 8 September beta, is not supported in this beta: start a new install instead. And it is core only. Plugins are not published with this release; the plugin host is in, and relayhall.plugins.json ships with an empty list.

This is a fast-track beta. Features land rough and are hardened later, and a known security and hardening backlog is open. Run it for evaluation and trusted teams, behind HTTPS, and keep backups.

Install it

You need a Linux host with Docker Engine, Docker Compose 2.24 or newer, OpenSSL and Git, and about 2 GB of RAM and one CPU core for a small installation.

git clone https://github.com/relayhall/relayhall.git
cd relayhall
git checkout v1.0.0-beta.102
./setup.sh
docker compose config --quiet
docker compose up -d --build --wait

The first start builds the images and runs the whole database setup before the API opens, so it can take several minutes. Then open http://localhost:8082/dashboard/ on the Docker host and choose Create the first administrator.

./setup.sh writes .env with a generated database password and signing secret, asks for a break-glass dashboard password (only its bcrypt hash is stored), and asks for the host name, scheme and port your browsers will use. It generates the backend’s four key sets into relayhall.keys.env and never changes a key that exists. Back up relayhall.keys.env with your database backups, and keep that copy apart from the dumps. Data stored under a key cannot be read without it.

The stack listens on 127.0.0.1 only. Another machine reaches it through a TLS reverse proxy that you run; the Domain and TLS section of DEPLOYMENT.md has a Caddy site and an nginx server block. The full path is in the README and the getting-started guide, and the whole release note is on the GitHub Release. The Get started page has the same commands.

A fresh board has no Tasks, Projects or Reports. It has five built-in Personalities, five starter Skills and your Account.

What is new

First install and sign-in. A fresh install can connect an agent, record telemetry and MCP sessions, and run knowledge searches from the start. Agent setup packs, the MCP and CLI lines and single sign-on name the address you declared, including its port and its https scheme. Where the browser will not keep the session cookie (plain HTTP away from localhost), the sign-in and first-run screens say so before you type, and a board without its keys answers with a named error that says what to run.

Board and Tasks. Every Task has a verification mode: human, service or none. A Task with mode none has no Verifier and completes at handback, so the next Task in a chain can read the Report and carry on. Only the Task’s Shepherd, an administrator or the Account can choose none, never an Agent. A Project and each of its Phases can name a default Verifier, which new Tasks inherit. Task cards show one honest activity badge (Active, Idle, Stale, Unknown or Unavailable) drawn only from telemetry a connected tool reported for that Task. The current Assignee can save progress Reports while the Task is in progress, and the finish step hands everything back into review in one atomic step. The Map sizes each area to the cards shown, with a Collapsed or Expanded Reports control and a Map and list view. Restricted Phases stay hidden: a Brief, a Project’s Phase list and a Warrant’s linked objects no longer show the name, goal or description of a Phase the viewer cannot read.

Permissions, ownership and Groups. A Group can record owners and managers. A Project, Task or Report can be owned by a Group, and every active member can read and use it. Navigation follows your role: everyone gets the Member view, administrators on a signed-in session also get an Administration group with Directory, Groups, People, Access and Advanced, and people who own or manage a Group get My team. A lens only chooses what the menu shows; every page and route still makes its own access decision. Directory shows identity providers and directory sync health, and one step turns a remote group into a bound Group. Access grants show where each one came from, and revoking asks for a step-up. New read-only Access Explorer routes answer who can do what on an object, and why. Skills now have owners.

Change requests. A new kind of approval asks for one change to an Account, a Group or an object: grants, credential scopes, knowledge compartments, roles, the owner, default Verifier or visibility of a Project, Phase, Task or Report, a Charter revision and more. File one from a Project’s Access and capabilities tab, from the Knowledge page, through the relayhall_access_request MCP tool or the CLI. Root, an administrator or the owner of every named object decides, on a signed-in session with one step-up; grant edits and revocations need a root session. A decider can only narrow a request, never widen it, and nobody can decide a request about themselves.

Harness connections. The Connect your agent wizard has templates for Claude Code, Codex, VS Code and Antigravity. Each makes one connector with one token, registered and published in the same step. The token carries sixteen scopes and never root, an admin scope or services:write. On Windows, one line (relayhall connector install) stores the token with Windows DPAPI, writes the client’s MCP entry and registers a per-user sign-in task, so the client never holds the token. An optional daemon mode listens for wake calls from the board and applies a local policy on what work it accepts. See the limits below for platform support.

Action Center. The notification centre is now the Action Center, with tabs for Notifications, Timeline, Approvals, My requests and Agent sessions. Needs your action lists the Decisions, Verify requests, Stuck Tasks and Skill reviews waiting on you, longest-waiting first, and the bell counts only unseen items. A read-only MCP tool and CLI command let an agent read a person’s queue so you can review it together; they cannot decide or mark anything.

Knowledge. The Knowledge page is now a search console over the sources you may read, with results grouped by source, a score, a “Why this matched” explanation and a side panel for reading. The board’s own Reports are searchable from the start through a built-in source. An administrator can register a source by confirming its TLS fingerprint, and agents can propose, preview and commit a note to a source that supports it. RelayHall does not ship an external knowledge source; you bring one.

Plugin host. Administrators set each installed plugin to required, default on, available or disabled with no restart, and people switch available plugins on or off under My plugins. Plugins can declare settings, draw sidebar widgets and show bridge metrics. OTLP over HTTP is accepted for traces, logs and metrics under /api/telemetry/otlp/v1/, with an optional gRPC listener that is off by default.

MCP and CLI. The MCP surface grows from 58 to 94 tools, with Task, Phase, Subtask, Report, access and knowledge tools, and every free-text field is marked as untrusted data. The CLI is still one standard-library Python script with nothing to install, and its new verbs cover almost everything the MCP tools do. Write verbs take --idempotency-key.

Phone layout and build. Dashboard pages were checked at 375 and 320 pixels wide with no sideways scroll, and every image now builds on a patched Node.js 22.23.4.

Fixed since the first public beta

A fresh install answered 500 when you connected an agent (issue #4). The key set that encrypts credential secrets was never created or passed to the backend. setup.sh now generates it, with the other three key sets, and Compose passes it on.
The dashboard redirect lost the port (issue #3). Every redirect from the frontend is now relative, so opening / or /dashboard keeps the port and scheme you used, also behind a TLS proxy.
Agent setup packs no longer name the wrong address, sign-in over plain HTTP no longer fails without a word, telemetry, MCP session records and knowledge search work from the first start, and the config file is now readable by the backend.

What is still rough

Sign-in needs HTTPS or localhost. The session cookie is marked Secure, so browsers do not keep it on a plain HTTP address that is not localhost, and health checks pass while sign-in fails. Use http://localhost:8082/dashboard/ on the Docker host, or put HTTPS in front with a reverse proxy and answer https and the proxy’s port when setup.sh asks for the public address.
The local connector installer runs on Windows only. On macOS and Linux its commands stop with exit code 3; use the “Set up by hand instead” blocks in the Connect your agent wizard, and protect the file they write the token into.
A knowledge source of your own needs a credential you place yourself. Compose does not forward the variable that holds a source’s channel bearer, so you add it to .env and an override file as the release note describes. Until then, searches of a registered source answer unavailable:transport. The source’s certificate must also chain to a public certificate authority.
Windows checkouts can break the shell scripts. Clone inside WSL2, or clone with git clone -c core.autocrlf=input https://github.com/relayhall/relayhall.git: a checkout that converts the shell scripts to Windows line endings stops the first start. A fix that pins line endings in the repository is on its way.
Other limits include how the board behaves under heavy load and the Map on very large boards. The README lists them.
Hardening is pending. A security and hardening backlog is open and comes after the planned features.

What comes next

No dates. The direction is a hardening pass, knowledge out of the box (a source you can install and register without bringing your own), plugins published separately from the core, setup beyond Windows and more kinds of harness, and more manager tools for delegated Group administration. The roadmap on the About page tracks the status.

Tell us where it fights you

Found a bug or a rough edge? Open an issue with the version, the expected result and a small reproduction. For a vulnerability, follow the security policy and report it privately. The changelog has the full list of changes.

Thank you to everyone who tried the first beta, filed issues and told us where it hurt.