Hosted onboarding
Reach your board from anywhere without opening a port. Your huskies stays on your own hardware and dials out to huskies.dev; we tunnel your team's traffic back down that one connection. Setting it up is five minutes and nobody to email.
What you need first
- A huskies instance already running on your own machine (Quickstart).
- Its node id — the public half of the identity in
.huskies/node_identity.key. Print it withhuskies node-id. Sixty-four hex characters. The private half never leaves your machine and is never sent to us.
The five steps
Sign up at huskies.dev/signup, then the app at huskies.dev/app walks you through the rest. It asks the server which step you are on, so closing the tab and coming back resumes rather than restarts.
-
Create an account. Email and password. This is the owner account: billing hangs off it, and it is how you get back in if everything else goes wrong.
-
Name your org. The name becomes your address. "Acme Robotics" gets you
acme-robotics, and your board lives athttps://acme-robotics.huskies.dev/board/. You can type a different address if the derived one is not what you want. -
Invite your team. Each invite is a link that works once and expires in a fortnight — send it however you already talk to each other. Whoever opens it while signed in joins the org. Invites grant
memberoradmin; only the account that created the org is its owner. -
Register your huskies. Paste the node id. The page answers with the exact config to paste back:
Restart huskies, and it dials out.# .huskies/project.toml, on the machine running your huskies rendezvous_url = "wss://huskies.dev/api/leader-rendezvous" # rendezvous_leader_id is optional and defaults to your node id # (<the key you just registered>). Restart huskies after saving. -
Open your board. It is live at your org's own address, for your members and for nobody else.
What crosses the wire, and what does not
Your pipeline, stories, board state and chat history stay in your project's own SQLite, on your own machine. We hold your account, your org, who is in it, and which public keys belong to you — nothing else. That is what makes leaving cheap: stop dialling out and you have lost nothing, because we never held it.
The agent surface does not traverse the tunnel at all. There is no MCP frame in the protocol and your huskies refuses the route independently, so hosting your board does not hand anybody remote agent access to your machine.
Who can see the board
Two things are required on every request: a huskies.dev session, and membership of the org the address belongs to. A signed-in stranger gets the same refusal whether or not your leader is online, so the board is not a way to find out that your org exists.
Removing somebody from the org takes effect within seconds — on the next page load, and on event streams and websockets they already have open, which are re-checked rather than trusted for as long as the tab stays up.
When it does not work
| What you see | Why | What to do |
|---|---|---|
| "Leader offline" | Your huskies is not dialling out. | Check the rendezvous_url line matches what the page showed, and that you restarted huskies. Registering a key and connecting are separate events. |
| Refused at the rendezvous, "not registered to any tenant" | The key that dialled is not the key you registered — usually a different machine, or a regenerated node_identity.key. |
Register the node id of the machine that is actually dialling. |
| "that leader pubkey is already claimed" | One key belongs to exactly one org, globally. | If it is genuinely yours, another of your orgs holds it. Otherwise generate a fresh identity. |
| An invite link says it is not valid, or already used | One link, one seat. | Ask for a fresh one — mint a link per person rather than sharing one. |
| "Not your board" after accepting an invite | The board link was followed before the invite was accepted. | Accept first; the next request works. |
[hosting] and [database] configuration behind all of this — is in deploy/onboarding.md in the huskies-server repository.