Compile the extension in a dedicated glibc builder stage (official
postgres:<major> image with PGDG headers, the same toolchain that builds
the release artifacts) instead of installing an apt toolchain into the
Supabase base, and resolve pg_config in the runtime stage by probing the
Nix profile paths instead of hardcoding the Ubuntu-only location. The
runtime stage no longer needs a compiler or package manager, so the
Ubuntu/Alpine userland difference stops mattering; both families run a
Nix-built, glibc-linked PostgreSQL, so the same .so serves both.
postgres-supabase-build derives the builder's PG major version from the
resolved base image tag, so auto-detection from a running Supabase CLI
stack picks matching headers for PG15 vs PG17.
Verified: CREATE EXTENSION cloudsync + cloudsync_version() on Alpine
17.6.1.151 and Ubuntu 17.6.1.071 / 15.8.1.135.
Closes #60
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Closes #60.
The local build-from-source path (make postgres-supabase-build, docker/postgresql/Dockerfile.supabase) assumed an Ubuntu-userland Supabase base: it installed its toolchain with apt-get and hardcoded the Ubuntu-only pg_config path, so it broke as soon as the Supabase CLI bundled an Alpine-based Postgres image (PG17 17.6.1.084+). #58 fixed the published release image; this is the deferred counterpart.
Approach
Both Supabase base families run a Nix-built, glibc-linked PostgreSQL (verified: the server binary's ELF interpreter is the Nix store's ld-linux, with versioned GLIBC_* symbols — Alpine/musl is only the surrounding userland). So instead of porting apk/apt toolchain detection into the build, the extension is now compiled in a dedicated glibc builder stage:
Verification
make postgres-supabase-build SUPABASE_POSTGRES_TAG=<tag> followed by CREATE EXTENSION cloudsync; SELECT cloudsync_version(); (as supabase_admin) returns 1.1.2 on:
The installed cloudsync.so in the Alpine image references versioned GLIBC_* symbols, confirming the matched-libc artifact.
🤖 Generated with Claude Code