robin.berjon.com / matey
This repository has no description
Star
Fork 0
Watch
matey deploy sm
3 folders · 2 files
matey-auth
matey-counter
matey-matrix
prepare.mjs
README.md
README.md

Deploying the Matey demo with sm (mycopunk.it) #

Deploys the demo behind the supramundane Caddy front (~/Code/darobin/caddy-front) as three services:

Service Domain What
matey-auth matey-auth.mycopunk.it the Matey broker (AT auth adapter)
matey-matrix matey-matrix.mycopunk.it Tuwunel homeserver (native next-gen auth; broker as its identity provider)
matey-counter matey-counter.mycopunk.it the counter demo app (static SPA)

One-time setup #

  1. DNS: point the three subdomains above at the supramundane server (the front's automatic ACME needs them resolving before first deploy).

  2. Secrets: one shared secret ties Tuwunel to the broker:

    cd deploy/sm
cp matey-auth/.env.example matey-auth/.env
cp matey-matrix/tuwunel.toml.example matey-matrix/tuwunel.toml
openssl rand -base64 32   # paste into BOTH files (client_secret / MATEY_BROKER_CLIENT_SECRET)

    Both files are git-ignored and travel to the server via sm deploy's rsync.

  3. Data-dir ownership: the broker container runs unprivileged (uid 1000) but sm creates the data dir as root, so once, after the first matey-auth deploy:

    ssh $SM_REMOTE_USER@$SUPRAMUNDANE 'chown 1000:1000 /srv/supramundane/data/matey-auth && docker restart matey-auth'

    (Symptom if skipped: matey-auth crash-loops on EACCES /data/broker.keys.json and Tuwunel reports a 502 for the broker's openid-configuration at login.)

Every deploy #

pnpm sm:prepare        # builds counter → matey-counter/site, broker → matey-auth/dist

cd deploy/sm/matey-auth    && sm deploy
cd ../matey-matrix         && sm deploy
cd ../matey-counter        && sm deploy

Order matters on first deploy only (Tuwunel validates its identity provider by talking to the broker; the app needs both). sm deploy wires each service into the front and reloads it.

Smoke checks:

curl https://matey-auth.mycopunk.it/.well-known/openid-configuration
curl https://matey-auth.mycopunk.it/atproto/client-metadata.json
curl https://matey-matrix.mycopunk.it/_matrix/client/v1/auth_metadata
curl https://matey-counter.mycopunk.it/oauth-client-metadata.json

Then open https://matey-counter.mycopunk.it, enter your handle, and walk the flow (no mooring → "create an account on matey-matrix.mycopunk.it" → PDS consent → provisioned account → run the linking ceremony from the banner).

Notes #

  • Federation is delegated to :443 via Tuwunel-served /.well-known/matrix/server (well_known.server in tuwunel.toml), since the front only exposes 80/443 — no :8448 needed.
  • Server name is permanent: matey-matrix.mycopunk.it is baked into the Tuwunel database (the sm data dir …/data/matey-matrix). To rename, wipe it.
  • Broker keys persist in …/data/matey-auth (id_token signing + atproto client keys). Wiping them rotates the broker's identity; in-flight logins die, nothing else.
  • The counter app is built with VITE_DEFAULT_HOMESERVER=matey-matrix.mycopunk.it and serves its own atproto client-metadata document (for the ceremony's identity:* session). Different hosts: override MATEY_COUNTER_HOST / MATEY_MATRIX_HOST when running pnpm sm:prepare, and edit the two service.json domains + the two secret files to match.
  • The other deployment route (plain docker-compose with its own Caddy) remains in deploy/ for non-supramundane hosts; known Tuwunel-topology limitations are listed in deploy/README.md and spec Appendix B.1.