Support newer Alpine-based Supabase Postgres images

Summary

Supabase's Postgres images switched their userland from Ubuntu to Alpine for the
current PG17 line (~17.6.1.084 and later). This PR makes the published
sqlitecloud/sqlite-sync-supabase images build cleanly on those newer bases, in
parallel with the existing Ubuntu-based images, and refreshes the pinned base tags.

Key finding: despite the Alpine userland, the PostgreSQL that actually runs on
these images is still a Nix-built, glibc-linked binary (every shipped plugin
needs libc.so.6 + a nix-glibc RUNPATH). So the existing glibc extension artifact
is the correct one — no musl build is required. Only the Dockerfile's build-time
userland tooling (apt-get vs apk) and the pg_config path differ between bases.

Changes

• docker/postgresql/Dockerfile.supabase.release — made userland-agnostic:
  • detects apk vs apt-get to install the curl used for the download,
  • resolves pg_config dynamically (path differs: /usr/bin on Ubuntu vs the Nix
    default profile on Alpine),
  • installs the same glibc artifact on both; the NIX_PGLIBDIR install logic
    was already portable and is unchanged.
    One file now serves both base families.
• .github/workflows/main.yml — docker-publish matrix:
  • added a PG17 Alpine row (base 17.6.1.151),
  • added a tag_suffix mechanism so Alpine publishes under distinct tags
    (:17-alpine, :17-alpine-<ver>, :17.6.1.151) with no collision against the
    :17 / :15 aliases,
  • bumped the PG15 base pin 15.8.1.085 → 15.8.1.135 (latest published 15 build;
    still Ubuntu — Supabase kept the 15 line on Ubuntu, 20.04→24.04).
• Docs:
  • docs/postgresql/quickstarts/supabase-self-hosted.md — documented the
    Ubuntu-vs-Alpine base split, added the :17-alpine image option, updated the
    PG15 base reference to 15.8.1.135.
  • docker/README.md — note that the published release image handles both bases
    automatically, while the local build-from-source flow currently targets Ubuntu.
  • docs/internal/supabase-flyio.md — refreshed the illustrative PG15 base tag
    from 15.8.1.085 to 15.8.1.135 throughout.

Resulting published tags

The shared :17 / :15 aliases intentionally stay on the Ubuntu builds for now
(non-breaking for existing pins).

Verification (local, arm64)

Built each image with its staged glibc artifact and ran CREATE EXTENSION cloudsync; SELECT cloudsync_version(); → 1.1.2:

• 17.6.1.071 (Ubuntu / apt branch) — ✅
• 15.8.1.135 (Ubuntu 24.04 / apt branch) — ✅
• 17.6.1.151 (Alpine / apk branch) — ✅

Open points (please check)

1. :17 / :15 alias scheme — deferred by design. Alpine is behind explicit
   -alpine + exact-base tags. Decide whether/when :17 should point at Alpine
   (matching what current Supabase self-hosting pulls), with the Ubuntu build moved
   to e.g. :17-ubuntu.
2. PG17 Ubuntu row (17.6.1.071) — kept for back-compat. Supabase moved the PG17
   line to Alpine, so this row is frozen on an old Ubuntu base (nothing newer to
   bump to) but still builds and works. Decision: keep it; the only related question
   is the :17 alias in point 1 above.
3. amd64 not tested locally — only arm64 was validated here. The glibc mechanism
   is arch-independent and CI builds linux/amd64,linux/arm64; the first CI run is
   the real amd64 proof.
4. Local build-from-source (Dockerfile.supabase, make postgres-supabase-build)
   still targets Ubuntu bases (uses apt-get + hardcoded pg_config). Out of scope
   here, but if the Supabase CLI bundles an Alpine image, this breaks. Compile-in-image
   on Alpine was proven to work — easy follow-up if wanted.
5. Pin maintenance — 17.6.1.151 and 15.8.1.135 are exact pins and will age;
   bumping is a manual edit (same as before). Optionally we could resolve the latest
   base tag dynamically in CI, at the cost of build reproducibility. Recommend keeping
   pins.

Test plan

• CI multi-arch build succeeds for all three Supabase rows (amd64 + arm64).
• Pulled :17-alpine and :15 images load the extension (cloudsync_version()).
• Existing :17 consumers unaffected — the PG17 Ubuntu row is unchanged at
  17.6.1.071, so the base image and its postgres UID (101:102) stay as they are.
• Existing :15 consumers need a one-time chown — the 15.8.1.085 → 15.8.1.135
  bump crosses Ubuntu 20.04 → 24.04, which shifts the postgres UID 105:106 →
  101:102 and makes an existing data directory unreadable (pgsodium_root.key: Permission denied / FATAL: invalid secret key). Documented in the quickstart;
  the chown -R 101:102 migration is verified on a live deployment. New
  deployments are unaffected.

Update — review follow-ups

Three commits on top of the original feature commit.

c4faf47 — review fixes

• CI job name collision. The two PG17 rows both rendered as docker sqlite-sync-supabase pg17; the job name now includes tag_suffix.
• apk del curl was a live regression. curl is already present in the real 17.6.1.151 Alpine base — apk add only had to install ca-certificates — so the previous unconditional apk del curl would have stripped curl out of every published Alpine image. It is now removed only if it was not already in the base, and is not installed at all when a beta artifact is staged. The GNU tar install was dropped too; busybox tar extracts the release tarball.
• CLOUDSYNC_PG_CONFIG is an ARG, not an ENV, so --build-arg actually overrides it (it previously could not) and the empty value no longer leaks into the published image.
• Missing CLOUDSYNC_VERSION now fails with an actionable message instead of unbound variable.
• pg_config resolution tries the Nix profiles the Supabase bases ship before falling back to PATH, so the Ubuntu images keep the exact path they resolved to before this PR.

b5c621e — doc nits

:17-alpine added to the quickstart's "For Existing Deployments" block and to the release-notes body; the pinned CloudSync version in the Dockerfile usage example replaced with a placeholder.

1a3e635 — CI smoke test before publish

Each matrix row now builds amd64 natively, loads it, boots it and runs CREATE EXTENSION cloudsync; SELECT cloudsync_version(); before the multi-arch push, so a broken artifact cannot reach Docker Hub.

Measured cost on run 29998811353 — all five rows green:

Workflow wall clock: 778 s vs 738 s (+40 s) — docker-publish is not on the critical path. The push step dropped 17–22 s on every row, confirming the amd64 layers are reused from the builder cache; the remaining cost is the load export, which scales with image size (hence the large Ubuntu Supabase rows).

Open points now settled

• Point 3 (amd64 not tested) — resolved. The Alpine row's log shows CREATE EXTENSION → 1.1.2 on amd64, one second before the push begins. The real 17.6.1.151 base was additionally verified by hand on arm64 (full container boot + CREATE EXTENSION).
• Point 4 (local build-from-source) — tracked in Local build-from-source (Dockerfile.supabase) assumes an Ubuntu Supabase base #60. Dockerfile.supabase still
  hardcodes apt-get and /root/.nix-profile/bin/pg_config, so it holds the opposite
  assumption to the now-portable Dockerfile.supabase.release in this PR. It is never
  built in CI, and only breaks once the Supabase CLI bundles an Alpine image.
• Point 1 (:17 / :15 alias scheme) — stays deferred, now tracked in Ship :17-ubuntu before flipping the :17 Supabase alias to Alpine #59. Recommendation there: do not flip :17 until the Alpine image has been exercised inside a full Supabase stack, and ship :17-ubuntu one release ahead of the flip.

🤖 Generated with Claude Code