Verify the self-hosting options work together, not just individually #22

New Issue

2026-09-01T23:12:57Z

paulhitt commented

2026-09-01 23:12:57 +00:00

(Migrated from gitlab.com)

Ask: verify the self-hosting options actually work together as intended, not just
individually.

What already exists

Scripts/selfhost-smoke.sh runs the published quick start exactly as SELF-HOSTING.md
gives it, and it is good — it exists because the quick start broke silently for a day and
nothing in the repository ran those instructions. It boots the stack rather than only
validating YAML, which is the distinction that mattered: docker compose config renders
happily with no web network, and the failure only appears at up.

🔴 It is not wired into CI and cannot be, so it is a release-time check that depends on
somebody remembering.

What it does not cover — the combinations

The smoke test proves one relay boots and serves. It does not prove the pieces work
together:

Accounts. The app authenticates against an accounts service, not the relay
(SiteConfig.accountProvider, usesSharedAccounts). Can somebody self-host a relay
and use it with a published app, or does that require self-hosting accounts too? This
is the first question a self-hoster hits and the answer is not written down in one
place.
Federation. A self-hosted relay exchanging with relay.flamenet.io — never tested
end to end. /comparison claims cross-server messaging as shipped on Android.
Multi-homing. A mailbox on the hosted relay and one on a self-hosted one. Also a
/comparison claim.
Calls. TURN is required for most real networks. A self-hoster needs their own
coturn, and turnserver.conf must be owned by nobody or TURN 401s silently — a
trap already recorded once.
Push. A self-hoster has no Apple key, so iOS gets no wake-ups at all. Android's own
path does not need one. This is a real asymmetry and should be stated plainly on
/self-hosting rather than discovered.
No Redis. FN_REDIS_URL unset falls back to interval polling. Documented as
supported; worth confirming it still is.
ARM. The published image is amd64 only (kaniko builds for the runner's
architecture), so a Pi or an ARM VPS must use --build. The smoke test has a --build
mode; confirm it is exercised.

Done looks like

A matrix of what a self-hoster can and cannot do, published on /self-hosting, with each
row either verified or honestly marked as untested. The claims on /comparison about
running your own server should map to rows in it.

⚠️ Freeze in effect — verify and document, do not change.

Related: #16 (security review).

**Ask:** verify the self-hosting options actually work together as intended, not just individually. ## What already exists `Scripts/selfhost-smoke.sh` runs the published quick start exactly as `SELF-HOSTING.md` gives it, and it is good — it exists because the quick start broke silently for a day and nothing in the repository ran those instructions. It **boots** the stack rather than only validating YAML, which is the distinction that mattered: `docker compose config` renders happily with no `web` network, and the failure only appears at `up`. 🔴 **It is not wired into CI** and cannot be, so it is a release-time check that depends on somebody remembering. ## What it does not cover — the combinations The smoke test proves one relay boots and serves. It does not prove the pieces work *together*: 1. **Accounts.** The app authenticates against an accounts service, not the relay (`SiteConfig.accountProvider`, `usesSharedAccounts`). **Can somebody self-host a relay and use it with a published app, or does that require self-hosting accounts too?** This is the first question a self-hoster hits and the answer is not written down in one place. 2. **Federation.** A self-hosted relay exchanging with `relay.flamenet.io` — never tested end to end. `/comparison` claims cross-server messaging as shipped on Android. 3. **Multi-homing.** A mailbox on the hosted relay and one on a self-hosted one. Also a `/comparison` claim. 4. **Calls.** TURN is required for most real networks. A self-hoster needs their own coturn, and `turnserver.conf` must be owned by `nobody` or TURN 401s **silently** — a trap already recorded once. 5. **Push.** A self-hoster has no Apple key, so iOS gets no wake-ups at all. Android's own path does not need one. This is a real asymmetry and should be stated plainly on `/self-hosting` rather than discovered. 6. **No Redis.** `FN_REDIS_URL` unset falls back to interval polling. Documented as supported; worth confirming it still is. 7. **ARM.** The published image is amd64 only (kaniko builds for the runner's architecture), so a Pi or an ARM VPS must use `--build`. The smoke test has a `--build` mode; confirm it is exercised. ## Done looks like A matrix of what a self-hoster can and cannot do, published on `/self-hosting`, with each row either verified or honestly marked as untested. The claims on `/comparison` about running your own server should map to rows in it. ⚠️ Freeze in effect — verify and document, do not change. Related: #16 (security review).

paulhitt commented

2026-09-02 00:33:57 +00:00

(Migrated from gitlab.com)

mentioned in issue #44

paulhitt commented

2026-09-02 00:33:58 +00:00

(Migrated from gitlab.com)

mentioned in issue #45

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-relay#22