[7ttp]

TL;DR

fixes supabase start sitting about 10s on docker's first health check when the services are already up.

whats improved/fixed?

docker runs a container's first health check one full interval after it starts, and our interval is 10s.

so supabase start kept waiting on that check even when everything was ready sooner.

a restart with the issue's excludes went from about 12.8s to 5.2s.
a full stack restart went from about 14s to 8s db start and db reset get the same.

how?

containers with a docker healthcheck now get --health-start-interval 1s and a 10s start period when docker version shows API 1.44 or newer for the client binary, the client in use, and the daemon, so the first check runs about 1s in and the interval stays 10s after.

kong's check lived only in its image, so its spec now sets the same kong health check and gets those flags too.

Note

on engines without the flag (docker below API 1.44, podman) containers keep the 10s first check.

ref:

• closes: supabase start waits about 10 seconds for Docker's first health check after services are ready #7427

[github-actions]

CLI benchmark: no changes found

Commit b6d1b1a against develop at e365ad6 · 10 runs each · report only, never blocks merging

Command	Before	After	Change
supabase --version	145 ms	144 ms	no real change
supabase --help	149 ms	146 ms	no real change
supabase init	149 ms	150 ms	no real change
supabase migration new bench	153 ms	156 ms	no real change
supabase gen types --lang typescript --project-id replayfixtureprojref	176 ms	176 ms	no real change
supabase projects list	161 ms	161 ms	no real change
supabase functions list --project-ref replayfixtureprojref	167 ms	166 ms	no real change

API calls: unchanged for all 7 commands.

Binary size: 134.0 MB, unchanged.

Details: timing ranges, API calls per command, slowest phases

Timing ranges

Command	Before range	After range	Change	Verdict
supabase --version	142-149 ms	142-160 ms	0 ms (0%)	within noise
supabase --help	145-162 ms	144-150 ms	-3 ms (-2%)	within noise
supabase init	146-153 ms	148-165 ms	+1 ms (+1%)	within noise
supabase migration new bench	152-160 ms	152-163 ms	+4 ms (+3%)	within noise
supabase gen types --lang typescript --project-id replayfixtureprojref	171-186 ms	174-189 ms	+0 ms (+0%)	within noise
supabase projects list	159-162 ms	158-176 ms	0 ms (0%)	within noise
supabase functions list --project-ref replayfixtureprojref	161-185 ms	161-180 ms	-1 ms (-1%)	within noise

API calls per command

Command	Before	After	Endpoint changes
supabase --version	0	0
supabase --help	0	0
supabase init	0	0
supabase migration new bench	0	0
supabase gen types --lang typescript --project-id replayfixtureprojref	2	2
supabase projects list	1	1
supabase functions list --project-ref replayfixtureprojref	2	2

Slowest phases

No command moved beyond noise, so there are no phase deltas.

Comment /bench to run it again on the latest commit.

Workflow run

[github-actions]

Superseded by a newer AI review

🤖 AI Review

Both independent reviews completed and reported no findings. Code inspection of the Docker API gating, health-start flags, and Kong readiness changes found no additional actionable issues.

Findings

No issues found.

Stats

Claude findings: 0 · Codex findings: 0 · Confirmed: 0 · Refuted: 0 · Uncertain: 0

---

Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.

[avallete]

Dogfooded locally on Docker (API 1.56) against develop: start with the issue's excludes, full stack restart, db start, db reset, status and stop all pass and are noticeably faster. The db container gets the 1s start interval and 10s start period, and kong answers /rest/v1/ with 200 when start returns.

Non-blocking notes:

• With [api.tls] enabled, the kong starting probe goes to https:// on the local port. If the HTTP client doesn't trust the local cert, it fails quietly and falls back to the 10s wait (no breakage, just no speedup).
• On a non-loopback services host (remote Docker or SUPABASE_SERVICES_HOSTNAME) with a proxy that doesn't exclude it, a proxy response could count as kong ready. Loopback already bypasses proxies and the existing gateway-reachable fallback has the same exposure, so not introduced here.
• A few new comments use /* */ instead of /** *////, and the HEALTH_START_PERIOD_SECONDS and localApiUrl ones could be clearer.

Not covered: Docker API < 1.44 and Podman.

[avallete]

/ai-review

[github-actions]

🤖 AI Review

Verified both reported findings against the checked-out code. Confirmed one JSDoc nit; the claimed Docker documentation inaccuracy remains uncertain. Codex reported no findings. No runtime defects were verified.

Findings

Severity	Location	Category	Sources	Claim
⚪ NIT	apps/cli/src/command-internal/db-bootstrap/docker-create-args.ts:26	documentation	claude	The startIntervalSeconds field uses a plain block comment containing a JSDoc link, so TypeScript editors will not expose that documentation or resolve its link on hover.
⚪ NIT	apps/cli/src/commands/stop/SIDE_EFFECTS.md:166	documentation	claude	The documentation attributes the three-version minimum to Docker, although the reviewer claims checking DefaultAPIVersion is an additional conservative CLI restriction.

Stats

Claude findings: 2 · Codex findings: 0 · Confirmed: 1 · Refuted: 0 · Uncertain: 1

---

Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: manual · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.