True air-gapped self-hosting #71

New issue

Closed

opened 2026-09-21 18:07:08 +01:00 by cruelacid · 1 comment

cruelacid commented

2026-09-21 18:07:08 +01:00

Owner

Part of #37. Category 4: structurally impossible for Relay.

What Relay cannot do

From their own relay-server-template/README.md:

"It is technically possible for the Relay control plane to issue an access
token and then use it to connect to your Relay Server if it is hosted on the
public internet. To ensure that your documents are fully private, you need to
host your Relay Server on a private network such as a tailscale tailnet or a
corporate VPN. If you host your Relay Server on the public internet, we
reserve the right to drop it from our network."

And from their user-facing docs, under "But you run the control plane — why
can't you grant yourselves access?":

"Nothing cryptographic stops us: our control plane could mint a valid access
token for any Shared Folder, and your Relay Server would accept it."

So self-hosting Relay buys privacy from Relay plus a VPN the customer also has
to run. Full air-gapped deployment is an enterprise waitlist item.

This is structural, not careless: if the server reads plaintext, anyone who can
authenticate can read plaintext, and network reachability is the only defence
left. They documented it plainly, which is more than most would — the claim is
"their self-hosting requires a VPN to be private, by their own documentation;
ours does not", never that they are dishonest.

What we can do

Our server holds no keys. A token we minted ourselves would yield ciphertext
under HMAC'd document names. Privacy of a self-hosted Nectenda depends on neither
a VPN nor on trusting us.

What this issue is for

Making sure that stays true as the hosted service grows, and that
docs/self-hosting.md can be followed to a genuinely air-gapped deployment —
including the open item that docker pull currently names an image in no
registry. Interacts with #68.

Risk

risk:none.

Part of #37. **Category 4: structurally impossible for Relay.** ## What Relay cannot do From their own `relay-server-template/README.md`: > *"It is technically possible for the Relay control plane to issue an access > token and then use it to connect to your Relay Server if it is hosted on the > public internet. To ensure that your documents are fully private, you need to > host your Relay Server on a private network such as a tailscale tailnet or a > corporate VPN. If you host your Relay Server on the public internet, we > reserve the right to drop it from our network."* And from their user-facing docs, under *"But you run the control plane — why can't you grant yourselves access?"*: > *"Nothing cryptographic stops us: our control plane could mint a valid access > token for any Shared Folder, and your Relay Server would accept it."* So self-hosting Relay buys privacy from Relay **plus a VPN the customer also has to run**. Full air-gapped deployment is an enterprise waitlist item. This is structural, not careless: if the server reads plaintext, anyone who can authenticate can read plaintext, and network reachability is the only defence left. They documented it plainly, which is more than most would — **the claim is "their self-hosting requires a VPN to be private, by their own documentation; ours does not", never that they are dishonest.** ## What we can do Our server holds no keys. A token we minted ourselves would yield ciphertext under HMAC'd document names. Privacy of a self-hosted Nectenda depends on neither a VPN nor on trusting us. ## What this issue is for Making sure that stays true as the hosted service grows, and that `docs/self-hosting.md` can be followed to a genuinely air-gapped deployment — including the open item that `docker pull` currently names an image in no registry. Interacts with #68. ## Risk `risk:none`.

cruelacid added this to the Backlog - unscheduled milestone

2026-09-21 18:07:08 +01:00

cruelacid added the

labels

2026-09-21 18:07:08 +01:00

cruelacid referenced this issue

2026-09-21 18:08:51 +01:00

Relay feature parity, with end-to-end encryption (tracking) #37