supabase start: vector container segfaults on native arm64 (Apple Silicon), execve EFAULT loading vector:0.53.0-alpine

[sinashamsizadeh]

Affected area

Local development / Docker

Supabase CLI version

v2.116.0 (also reproduces on v2.75.0)

Operating system

macOS 26 (Darwin 25.6.0), Apple Silicon (arm64). Docker Desktop 4.57.0.

Installation method

brew

Command

supabase start

Actual output

Starting containers...
Waiting for health checks...
supabase_vector_<project> container logs:
Segmentation fault
Segmentation fault
Segmentation fault
[repeats]
Stopping containers...
{"_tag":"Error","error":{"code":"LegacyHealthCheckTimeoutError","message":"supabase_vector_<project> container is not ready: unhealthy"}}

Expected behavior

The vector (analytics/log) container starts and passes its health check like the rest of the stack.

Steps to reproduce

1. On an Apple Silicon Mac with Docker Desktop 4.57.0 (macOS 26 / Darwin 25.6.0), run supabase init (or use any project with [analytics] enabled = true in supabase/config.toml, the default).
2. Run supabase start.
3. The supabase_vector_* container logs repeated Segmentation fault and never becomes healthy; supabase start fails with LegacyHealthCheckTimeoutError.

Minimal repro without the CLI, isolating the exact image the CLI hardcodes (vector:0.53.0-alpine):

docker run --rm --platform linux/arm64 --entrypoint vector public.ecr.aws/supabase/vector:0.53.0-alpine --version
# exit code 139 (SIGSEGV), no output

strace shows the process never actually starts running vector's code — the crash happens inside the kernel's own binary loader:

$ docker run --rm --platform linux/arm64 --entrypoint sh public.ecr.aws/supabase/vector:0.53.0-alpine \
    -c "apk add --no-cache strace >/dev/null 2>&1; strace vector --version"

execve("/usr/local/bin/vector", ["vector", "--version"], 0xffffcb3b0258 /* 5 vars */) = -1 EFAULT (Bad address)
+++ killed by SIGSEGV +++
Segmentation fault

Isolation that points at this specific image/tag rather than the host or Docker Desktop in general:

• The same image tag run under --platform linux/amd64 (Rosetta emulation) works fine:

  docker run --rm --platform linux/amd64 --entrypoint vector public.ecr.aws/supabase/vector:0.53.0-alpine --version
  vector 0.53.0 (x86_64-unknown-linux-musl 2b51b40 2026-01-27 21:46:39.386326724)
  

• The older pinned image, public.ecr.aws/supabase/vector:0.28.1-alpine, runs fine natively on arm64 on the same host:

  docker run --rm --platform linux/arm64 --entrypoint vector public.ecr.aws/supabase/vector:0.28.1-alpine --version
  vector 0.28.1 (aarch64-unknown-linux-musl ff15924 2023-03-06)
  

• Not a resource constraint: Docker Desktop VM has 188G free disk and 7.1G free RAM; passing --memory=2g explicitly makes no difference.

So the arm64 build inside public.ecr.aws/supabase/vector:0.53.0-alpine specifically appears to be a broken/malformed binary for this loader — every other build (older arm64 tag, same tag's amd64 build) loads and runs correctly.

There is currently no way to work around this from CLI/config: supabase/config.toml has no field to override the vector image or tag, and the tag is hardcoded in the CLI binary (only SUPABASE_INTERNAL_IMAGE_REGISTRY exists, which swaps the registry host, not the tag). No newer tag (e.g. 0.53.1-alpine, 0.54.0-alpine) is published yet.

Docker and service versions

$ docker version
Client: 29.1.3 (darwin/arm64)
Server: Docker Desktop 4.57.0 (Engine 29.1.3, containerd v2.2.1, runc 1.3.4), linux/arm64
Kernel Version: 6.12.54-linuxkit

$ supabase services
supabase/postgres        17.6.1.165
supabase/gotrue           v2.196.0
postgrest/postgrest       v16.1
supabase/realtime         v2.129.3
supabase/storage-api      v1.70.3
supabase/edge-runtime     v1.74.3
supabase/studio           2026.08.17-sha-0c1da8f
supabase/postgres-meta    v0.98.0
supabase/logflare         1.50.4
supabase/supavisor        2.9.7

Additional context

Workaround for anyone hitting this: run supabase start (or any pnpm/npm wrapper around it) with DOCKER_DEFAULT_PLATFORM=linux/amd64 set, which forces all local containers (including vector) to run under the emulated x86_64 build instead of the broken native arm64 one. Slower, but functional until this is fixed.

[mandar1045]

I looked into the binary, and the issue seems to be with vector:0.53.0-alpine. It has a problem that causes it to fail on newer arm64 LinuxKit kernels. Updating to 0.58.0-alpine fixes it.

Could a maintainer add the open-for-contribution label so I can reopen the PR?

[hsusul]

Request: open-for-contribution label

CONTRIBUTING.md says external PRs need the open-for-contribution label or the Contribution Gate auto-closes them.

A fix is ready: bump the hardcoded Vector image pin from timberio/vector:0.53.0-alpine → 0.58.0-alpine (Dockerfile + stack ServiceCatalog defaultVersion, plus unit tests that asserted the old pin). This targets the native arm64 segfault / execve EFAULT on Apple Silicon reported here.

I'll open a PR linking Closes #6479 so the change is reviewable; please add open-for-contribution when triage allows so the gate does not close it.