fix(supabase): add healthchecks to rest and functions services

[Carlos-Vera]

What this PR does

Adds a healthcheck to the rest (PostgREST) and functions (edge-runtime) services of the Supabase template. No image versions are changed.

Why

Both services ship without a healthcheck at either the image or the compose level, so Docker reports them as plain Up with no health state. kong and meta also omit a compose-level healthcheck, but their images carry one, so Docker still reports them healthy.

EasyPanel aggregates per-container health into the service status, so a container with no health state keeps the whole compose service from ever reading as healthy, even when everything works. It also weakens restart-on-unhealthy and any depends_on: condition: service_healthy gating.

Reported in #77.

How

rest — the PostgREST image is distroless (no sh/bash/curl/wget), so a CMD-SHELL check cannot run inside it. PostgREST v14 ships a --ready CLI flag: the binary itself queries its admin server and exits non-zero until it is live and connected to the database. This branch is already on postgrest/postgrest:v14.8, so the flag is available.

    healthcheck:
      test: [ "CMD", "postgrest", "--ready" ]
      interval: 5s
      timeout: 5s
      retries: 3

The admin server is enabled with PGRST_ADMIN_SERVER_PORT: 3001 and PGRST_ADMIN_SERVER_HOST: localhost. It serves /live, /ready and /metrics without auth, but it is bound to localhost and the port is not published, so it is only reachable from inside the rest container — which is where the healthcheck runs. Residual risk only if someone rebinds the host to 0.0.0.0 or publishes port 3001.

functions — the edge-runtime image ships bash and the runtime listens on :9000 (the port Kong proxies /functions/v1 to), so a dependency-free TCP check works:

    healthcheck:
      test: [ "CMD", "bash", "-c", "exec 3<>/dev/tcp/127.0.0.1/9000" ]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 20s

Upstream

The rest healthcheck is the same one merged into supabase/supabase master in supabase/supabase#46658, from the issue I filed in supabase/supabase#46642. The postgrest --ready approach came from @aantti's review there. The functions check follows the proposal in that same issue.

Tested

Running on EasyPanel from a fork of this branch for ~22 hours, project walterhaus-web:

walterhaus-web_supabase-studio-1      Up 21 hours (healthy)
walterhaus-web_supabase-functions-1   Up 22 hours (healthy)
walterhaus-web_supabase-rest-1        Up 22 hours (healthy)
walterhaus-web_supabase-db-1          Up 22 hours (healthy)
walterhaus-web_supabase-kong-1        Up 22 hours (healthy)
walterhaus-web_supabase-storage-1     Up 22 hours (healthy)
walterhaus-web_supabase-meta-1        Up 22 hours (healthy)
walterhaus-web_supabase-analytics-1   Up 22 hours (healthy)
walterhaus-web_supabase-realtime-1    Up 22 hours (healthy)
walterhaus-web_supabase-supavisor-1   Up 22 hours (healthy)
walterhaus-web_supabase-auth-1        Up 22 hours (healthy)
walterhaus-web_supabase-vector-1      Up 22 hours (healthy)
walterhaus-web_supabase-imgproxy-1    Up 22 hours (healthy)

Relation to update.js

Worth saying plainly: this edit does not survive a template regen — copyDir does rm -rf ./code and recopies supabase/docker wholesale. The rest healthcheck would come down on its own the next time the template is regenerated, since it is already in Supabase master.

The point of this PR is that a regen also pulls in everything else that landed upstream since this branch was cut, which is a much bigger change to hand to existing deployments. This is the small, low-risk version of the same fix, applied now.