Local build-from-source (Dockerfile.supabase) assumes an Ubuntu Supabase base

[andinux]

The local build-from-source path (docker/postgresql/Dockerfile.supabase, driven by make postgres-supabase-build) still assumes an Ubuntu-userland Supabase base. #58 made the published release image (Dockerfile.supabase.release) work on both Ubuntu and Alpine bases, but deliberately left this one out of scope.

Why it matters

make postgres-supabase-build auto-detects the base from whatever the Supabase CLI is running:

SUPABASE_CLI_IMAGE ?= $(shell docker ps --format '{{.Image}} {{.Names}}' | awk '/supabase_db/ {print $$1; exit}')

So this breaks by itself, without anyone changing our defaults, the moment the Supabase CLI bundles an Alpine-based Postgres image. Supabase has already moved the PG17 line to Alpine (17.6.1.084+), so this is a matter of when, not if.

The two failure points

1. Package manager — the builder stage installs its toolchain with apt-get, which doesn't exist on Alpine:

RUN apt-get update && apt-get install -y \

2. Hardcoded pg_config — both the builder and runtime stages pin the Ubuntu path:

ENV CLOUDSYNC_PG_CONFIG=/root/.nix-profile/bin/pg_config

On the Alpine bases pg_config lives in the Nix default profile (/nix/var/nix/profiles/default/bin/pg_config) instead, so the existing if [ ! -x ... ] guard fires and the build stops with Error: pg_config not found at /root/.nix-profile/bin/pg_config.

The fix

Port the logic already proven in Dockerfile.supabase.release:

• Detect apk vs apt-get and install the toolchain with whichever is present
• Resolve pg_config by probing the known Nix profiles in order, falling back to PATH, instead of hardcoding one path

Both bases run a Nix-built, glibc-linked PostgreSQL, so the compiled artifact itself needs no change — only the build-time userland tooling differs. Compiling in-image on Alpine was confirmed to work during #58.

Acceptance criteria

• make postgres-supabase-build SUPABASE_POSTGRES_TAG=17.6.1.151 (Alpine) produces an image where CREATE EXTENSION cloudsync; SELECT cloudsync_version(); succeeds
• The same command against an Ubuntu base (17.6.1.071, 15.8.1.135) still works
• Auto-detection via a running Supabase CLI stack works on both families

Related

• feat: support newer Alpine-based Supabase Postgres images #58 — made the published release image userland-agnostic; this is the deferred counterpart (its open point 4)
• Note the base families also differ in the postgres user's UID, which matters when reusing an existing data directory — see the migration note in docs/postgresql/quickstarts/supabase-self-hosted.md