Klaus
2d57db8182
check / flake-check (pull_request) Has been cancelled
Lays out the agreed shape from the design discussion: one flake at the root with three nixosConfigurations (mqtt-ingest, db-host, app-host), vendored Supabase docker-compose pointed at the external db-host, Caddy → Kong → PostgREST/GoTrue, a Go MQTT→Postgres ingester stub, deploy-rs node map, and a Gitea Actions workflow that deploys in db → app → ingest order on push to main. No real implementation yet — every host module has TODOs marking the gaps (real hardware config, actual hostnames, HiveMQ packaging, vendor the full upstream Supabase compose, etc.).
Supabase compose stack
Vendored from the official Supabase self-hosting bundle, with two deliberate changes:
-
The bundled
dbservice is removed. Every service that talks to Postgres readsPOSTGRES_HOST/POSTGRES_PORTfrom the environment and connects to the externaldb-host. The systemd unit (nix/modules/gebos-supabase.nix) injects these from/etc/gebos/secrets.env. -
Studio is bound to
127.0.0.1only. There is no public route to it. To use it from your laptop:ssh -L 3000:127.0.0.1:3000 app-host open http://localhost:3000This is intentional — Studio runs with the
service_roleJWT and bypasses RLS. Putting it on the public internet behind only HTTP basic auth (the default) is too thin.
What's in here
docker-compose.yml— the stack itselfinit.sql— schemas, roles, and extensions Postgres needs before the compose services come up. Loaded bynix/modules/gebos-postgres.nix.kong.yml— Kong's declarative routing (to be vendored alongside the compose file when we copy it in).
Updating the vendored compose
When upstream Supabase ships a new compose layout, re-vendor by:
- Copy upstream
docker/docker-compose.ymloverdocker-compose.yml. - Remove the
db:service block. - Replace every
db:5432/postgres:5432reference with${POSTGRES_HOST}:${POSTGRES_PORT}. - Bind Studio to
${STUDIO_BIND}:3000instead of0.0.0.0:3000. - Commit, deploy, smoke-test through the SSH tunnel.