supabase start: edge runtime fails with "failed to determine entrypoint" on 2.115.0 (works on 2.108.0) — main service single-file bind mount

[sheldonhall]

Affected area

Edge Functions / Local development

Supabase CLI version

2.115.0 (regression — 2.108.0 works)

Operating system

Windows 11 Pro

Installation method

Other (scoop)

Command

supabase start

Actual output

supabase_edge_runtime_<project> container logs:
DEBUG No .npmrc file found
DEBUG Finished config loading.
worker boot error: failed to bootstrap runtime: failed to determine entrypoint
Error: main worker boot error

Caused by:
    0: worker boot error
    1: failed to bootstrap runtime
    2: failed to determine entrypoint
Stopping containers...
supabase_edge_runtime_<project> unexpected status 503

Expected behavior

supabase start brings up the edge runtime, as it did on 2.108.0 and earlier. The whole stack now fails to start because of this one container.

Steps to reproduce

Requires a Docker daemon reached over TCP rather than the local named pipe/socket (my active docker context endpoint is tcp://<docker-host>:<docker-port>; the daemon is Docker Desktop 4.87.0 on another host).

1. supabase init, add any edge function.
2. supabase start with CLI 2.115.0 → failed to determine entrypoint, then unexpected status 503.
3. Downgrade to 2.108.0, supabase start → succeeds, edge functions serve normally.

Root cause

2.115.0 changed how the edge runtime's main service is delivered to the container, from inlining it to bind-mounting it as a single file.

2.108.0 — main service written via heredoc in the container entrypoint, no host bind involved:

Entrypoint: ["sh","-c","cat <<'EOF' > /root/index.ts && edge-runtime start --main-service=/root --port=8081 --policy=per_worker\n<script>\nEOF"]
Binds: [
  "supabase_edge_runtime_<project>:/root/.cache/deno:rw",
  "/run/desktop/mnt/host/c/Users/<user>/dev/<project>/supabase/functions:/Users/<user>/dev/<project>/supabase/functions/:ro"
]

2.115.0 — main service bind-mounted from a host temp file:

Cmd: ["-c","edge-runtime start --main-service=/root --port=8081 --policy=per_worker\n"]
Binds: [
  "C:\Users\<user>\dev\<project>\supabase\.temp\start-secrets\supabase_edge_runtime_<project>\main\index.ts:/root/index.ts:ro,Z",
  "supabase_edge_runtime_<project>:/root/.cache/deno:rw",
  "/run/desktop/mnt/host/c/Users/<user>/dev/<project>/supabase/functions:/Users/<user>/dev/<project>/supabase/functions:ro"
]

Two problems with that first bind on a non-local daemon:

1. The path isn't translated. Note the inconsistency within the same bind list — the functions directory is passed pre-translated as /run/desktop/mnt/host/c/..., but the main service file is passed as a raw Windows path C:\Users\.... Over a named pipe Docker Desktop translates that client-side, so local users never notice. Over TCP it is taken literally by the Linux daemon, doesn't exist, and Docker silently creates an empty directory at the destination.

2. Single-file binds don't survive the hop at all on this setup, even with a correctly translated path. Verified with a minimal repro, no Supabase involved:

$ echo 'export const x=1' > /c/Users/<user>/probe/b.ts
$ docker run --rm -v '/run/desktop/mnt/host/c/Users/<user>/probe/b.ts:/root/b.ts:ro' \
    --entrypoint sh public.ecr.aws/supabase/edge-runtime:v1.74.3 -c "ls -ld /root/b.ts"
drwxr-xr-x 1 root root 512 /root/b.ts       # <- directory, not the file

Directory binds work correctly — the supabase/functions mount is byte-identical inside the container (verified by md5sum). Only single-file binds fail.

So /root/index.ts is an empty directory, edge-runtime start --main-service=/root can't resolve an entrypoint, the health check never passes, and supabase start aborts with 503.

Confirmation inside the 2.115.0 container:

$ docker exec ... ls -ld /root/index.ts
drwxrwxrwx 1 root root 512 /root/index.ts
$ docker exec ... head -c 200 /root/index.ts
head: error reading '/root/index.ts': Is a directory

Suggested fix

Any of these would work, roughly in order of preference:

1. Restore the 2.108.0 behaviour (inline the main service, or docker cp it in). This needs no host filesystem sharing at all and is what every other service in the stack already does — kong, vector and analytics have no host binds whatsoever.
2. Bind the parent directory (...\main\) instead of the single file. Directory binds work fine here.
3. At minimum, apply the same path translation to this bind that is already applied to the functions directory bind.

This is likely the same root cause as #4190 (podman), where the container filesystem is similarly not the host filesystem.

Docker and service versions

Client:
 Version:           29.2.1
 API version:       1.53
 OS/Arch:           windows/amd64
 Context:           <remote context>  # tcp://<docker-host>:<docker-port>

Server: Docker Desktop 4.87.0
 Engine:
  Version:          29.7.2
  API version:      1.55 (minimum version 1.40)
  OS/Arch:          linux/amd64
 containerd:        v2.2.5
 runc:              1.3.6

edge-runtime image: v1.74.3 (2.115.0) / v1.74.2 (2.108.0)

Additional context

Workaround is to hold the CLI at 2.108.0. Paths and the daemon host above are redacted, otherwise verbatim. Happy to run further diagnostics on this setup if useful.

[sheldonhall]

Follow-up with a finding that narrows the fix, from the same setup.

On 2.108.0 — the version I rolled back to — supabase functions serve fails on Windows for an unrelated reason:

Setting up Edge Functions runtime...
{"_tag":"Error","error":{"code":"UnknownError","message":"ENAMETOOLONG: name too long, uv_spawn"}}

Bisected against local installs plus a download of 2.107.0:

version	functions serve
2.98.2 / 2.101.0 / 2.105.0 / 2.106.0 / 2.107.0	works
2.108.0	ENAMETOOLONG
2.115.0	failed to determine entrypoint (this issue)

Cause: in 2.108.0 the TS shim builds a docker run argv with the ~26KB main service script inlined as the final -c argument:

c = ["run","-d","--name",D,...,"--entrypoint","sh", image, "-c", F_$(d,u,b?.scriptPath)]

Windows caps a command line at ~32767 chars, so the spawn fails before Docker is contacted. Note b?.scriptPath — the file/bind variant already exists in 2.108's bundle, just unused.

Why this matters for the fix here: the three options I suggested above aren't equivalent.

• Reverting to the inline script reintroduces this Windows failure.
• The single-file bind (2.115.0) breaks any daemon that isn't sharing the local filesystem.
• Only handing the script over through the Docker API — or docker cp after create — avoids both.

Supporting evidence: supabase-go functions serve works correctly on this same machine at every version tested, including 2.108.0 and 2.115.0, because the Go binary talks to the Docker API rather than assembling a docker command line. That path is unaffected by either bug.

Environment as in the issue body: Windows 11 Pro, daemon reached over tcp://<docker-host>:<docker-port>.