what can 5dive actually touch on your server?
a prospect asked us this week: “what can 5dive actually touch on my server?” it’s the right question. you’re handing a company a box that runs agents with your credentials on it. here’s the honest answer.
one thing first, because it changes the whole story: this post is about managed 5dive.com boxes. if you self-host the open-source stack, the answer is simply “nothing”: no daemon, no tunnel, no 5dive key, ever, unless you add them yourself. everything below is about the managed product, where a control plane exists and therefore has to earn your trust.
the whole surface, in one list
on a managed 5dive box, the control plane is one small daemon and one tunnel:
- shelld, a single-file daemon at
/usr/local/lib/5dive/shelld.mjs, running asshelld.service. it does exactly three things for the dashboard: executes one whitelisted binary (/usr/local/bin/5dive, the open-source CLI, not a shell and not arbitrary argv), serves the file browser (read and write, rooted under/home), and runs the web terminal over a websocket. that’s the full feature list. it’s one file on your disk, so go count. - an outbound-only cloudflared tunnel with a bearer token minted for that one box. the management plane has no inbound port at all: your server dials out, never the other way. (SSH does listen inbound, on a custom port, because that’s your own door, not ours.) one box’s token is rejected by every other box.
- every management call is logged on your box: shelld writes a structured json line for each exec, file access, and key operation to
~/.5dive/access-log.jsonl, andjournalctl -u shelldcarries the same. your disk, not our cloud, and your dashboard now reads it back to you (below).
that’s the list. there is no standing SSH key: provisioning removes the 5dive admin key as its final step, and we verify the removal end to end. we wrote that up when we shipped it: we removed our own ssh key from your server.
getting in requires your consent
consent already had a button. in your dashboard’s danger zone there’s “grant support access”: you tap it, and a one-off keypair is minted for that incident. the public half lands in authorized_keys carrying sshd’s own expiry-time option, so the key dies in 24 hours by sshd’s clock, no cleanup job to trust, and granting again replaces the old key, so at most one support key is ever live. nobody at 5dive can open that window. only you.
and consent is enforced by the box, not by our policy. shelld refuses to install the 5dive admin key through any path except that button, matched by the key itself, on your hardware where our control plane cannot reach. your dashboard carries an access log reading shelld’s own on-box record: every support grant, every key sync, and every refused admin-key attempt, timestamped, on your disk. consent isn’t our policy, it’s the box’s rule.
that screenshot is our own box, and the refused attempt in it is real: our engineer fired an admin-key install at a live box to prove the guard holds. it did. no mockups in a security post.
the sovereignty option
if even that surface is too much, you can shrink it to zero. switching a box to self-managed strips our key, so the only SSH keys are yours. and because you have root, turning off the management plane entirely is two systemctl disables away, the shelld unit and the tunnel unit. after that the box is a plain server that happens to run your agents, and 5dive cannot touch it at all.
and that’s not a special concession, it’s the default shape of the open-source stack. run install.sh on your own hardware and there is no control plane anywhere unless you choose to add one. the code you’d be auditing is the same code we run on managed boxes.
why we publish this
your agents hold your telegram bots, your model subscriptions, your repos. the machine they live on should be boring to reason about: one daemon you can read, one outbound tunnel you can revoke, zero keys that aren’t yours, and an off switch for all of it.
if you want the version where you hold every key: 5dive.com, or self-host the stack and never talk to us again. both are fine with us.