Deploying for a small team (free tier)¶
This is the practical, end-to-end recipe for getting a handful of developers sharing Hive workspaces — on free or near-free hosting, in about 15 minutes.
What you're actually deploying¶
Hive is a desktop app; there's no central server to run for the app itself. The only thing a team self-hosts is the relay — a tiny stateless service that forwards encrypted events between devices. One relay serves your whole team.
┌────────────┐ ┌──────────────┐ ┌────────────┐
│ Dev A (app)│ ──push─▶│ hive-relay │◀─pull── │ Dev B (app)│
│ │ ◀─pull──│ (you host 1) │ ──push─▶│ │
└────────────┘ └──────────────┘ └────────────┘
every device with the same relay URL + room id converges
What you do not pay for centrally:
- LLM inference. Hive is bring-your-own: each developer uses their own Claude Code CLI subscription (the default runtime) or their own API key / local Ollama. There's no shared inference bill to provision.
- A database. The relay keeps state in memory; each device keeps its own SQLite event log. Nothing to back up on the relay.
So "deployment" for a small team is really just "host one small relay and share three values with your teammates."
Step 1 — Host one relay (free tier)¶
Pick a host. For a small team, two good free-ish options:
| Fly.io (recommended) | Render | |
|---|---|---|
| Stays always-on | yes (keep 1 machine) | no — free instances sleep when idle |
| First-request after idle | instant | slow (cold start), and queued events are lost on sleep |
| Setup | one CLI command | click through a Blueprint |
| TLS / HTTPS URL | automatic | automatic |
Because the relay holds queued events in memory, a host that sleeps will
drop anything a peer hasn't pulled yet. That's fine for an evening of pairing,
but for a team that's online at different hours, prefer Fly.io's always-on
single machine (its free allowance covers one shared-cpu-1x / 256 MB machine,
which is all the relay needs).
The relay lives in its own repo — github.com/honeyhive-ai/relay
(MIT) — which ships the Dockerfile + deploy/fly.toml. Clone it, then:
Fly.io¶
git clone https://github.com/honeyhive-ai/relay && cd relay
fly auth signup # or: fly auth login
fly launch --copy-config --no-deploy # first time — pick a unique app name + region
fly volumes create hive_data --size 1 --region <your-region>
fly deploy # this + later deploys
fly status # → https://<your-app>.fly.dev
Render / Railway / Cloud Run / a VPS¶
Point the platform at the relay repo's Dockerfile (New → Web Service → Docker),
attach a persistent disk at /data, set HIVE_RELAY_DATA_DIR=/data, and expose
port 8443. Or build + run the image anywhere:
docker build -t hive-relay https://github.com/honeyhive-ai/relay.git
docker run -d -p 8443:8443 --restart unless-stopped hive-relay
# put Caddy/nginx in front for HTTPS, or use the platform's TLS
The full deploy reference (env, TLS, token gating, Postgres/HA) lives in the relay repo's README. For the from-scratch / control build, see Self-hosting a relay.
Step 2 — Verify it's up¶
If you get ok, the relay is ready. There's nothing else to configure on it.
Step 3 — Agree on three values¶
Decide these once and share them with the team over a trusted channel (your password manager, a DM — not a public channel):
| Value | What it is | Example |
|---|---|---|
| Relay URL | the URL from Step 1 | https://acme-hive.fly.dev |
| Room | any shared string; same room = same workspace | acme-backend |
| Workspace key | shared secret → end-to-end encryption | a long passphrase |
The workspace key is your security model (see Step 5) — treat it like a password and don't skip it.
Step 4 — Each teammate connects (no restart, no env vars)¶
In Hive: Settings → Multiuser sync, fill in the Relay URL, Room, and Workspace key, then Save. The background sync picks it up within a few seconds — no relaunch needed. The status pill should read live (it reports real connection state — live / error / offline — so a bad key or dead relay shows as a Sync error, not a false "Live"):
Now create a chat on one machine; it shows up on the others within ~3 seconds. Replies, agents, proposals, reactions, and skills all propagate the same way.
Environment variables (
HIVE_RELAY_URL,HIVE_WORKSPACE,HIVE_WORKSPACE_KEY) still work, but they only seed the settings on first launch. After that the in-app Settings are the source of truth. Most teams don't need the env vars at all.
Each developer also points their own runtime at their own credentials — the
default claude CLI needs nothing beyond being logged in (claude); an
Anthropic/OpenAI key or a local Ollama goes in the same Settings panel. See
Configuring a runtime.
Step 5 — Security for a small team¶
The relay has no built-in login — anyone with the URL and the room id can join that room. Two things make that safe:
- Always set a workspace key. With it, every event is sealed with
ChaCha20-Poly1305 before it leaves the device; the relay only ever stores
ciphertext, and a peer with the wrong key can't read anything. Settings shows
🔒 encryptedwhen it's on,⚠ plaintextwhen it isn't. - Use an unguessable room id. Not
teamordev— something no one would stumble onto.
To remove someone's access, rotate: pick a new workspace key (and/or room), and re-share it with everyone who should stay. The old key can no longer decrypt new traffic.
If a teammate enables a higher Claude permission mode (Settings → Multiuser
sync → Claude permissions: acceptEdits / bypassPermissions), that lets the
claude agent edit files / run commands on their machine without asking —
it's local and off by default. Leave it on the safe default unless the
workspace is trusted.
Free-tier expectations & when to upgrade¶
For a team of a few developers, the relay's load is negligible — events are
small and infrequent, memory is ~1 KB per queued item, CPU is trivial. A single
free shared-cpu-1x machine is plenty.
Move up when you hit one of these:
| Symptom | Why | Fix |
|---|---|---|
| Peers miss events after quiet periods | free host slept and dropped the in-memory queue | always-on machine (Fly.io min 1) |
| You want events to survive a relay restart | state is in-memory only today | keep the machine up; durable storage is a tracked follow-up |
| You need real accounts / SSO / audit | relay has no auth by design | a managed/enterprise relay — see Pricing tiers |
Caveats (today's relay)¶
- Single instance. State is in memory — run exactly one machine, don't scale out, and know that a restart drops anything peers haven't pulled yet.
- No authentication. Security comes from the workspace key + an unguessable room id (Step 5), not from the relay.
- Direct P2P / TURN are tracked follow-ups; relay forwarding is the path that works today and is all a small team needs.
Checklist¶
- [ ] One relay deployed,
/v1/healthreturnsok - [ ] Relay URL + room + workspace key shared over a trusted channel
- [ ] Every teammate's Settings → Multiuser sync pill reads
live · 🔒 encrypted - [ ] Each developer has their own runtime credentials (claude login / API key / Ollama)
- [ ] Room id is unguessable; everyone has the workspace key