`supabase start` reports "already running" when all local containers are stopped

[marty-mkh]

After updating Docker Desktop on Windows to 4.81.0, my local Supabase containers no longer start automatically when Docker starts.

Running:

npx supabase start

returns:

supabase start is already running.
supabase_db_<project> container is not running: exited

The CLI refuses to start the existing containers because it considers the project "already running", even though every container is in the Exited state.

Expected behavior

After Docker Desktop starts, an existing local Supabase stack should either resume automatically (as it did previously) or supabase start should detect that the containers exist but are stopped and start them instead of reporting that the project is already running.

Actual behavior

All containers exist but are stopped:

docker ps -a

shows all supabase_* containers in Exited state.

The following works correctly:

docker start $(docker ps -aq --filter "name=supabase_")

and also:

npx supabase stop
npx supabase start

This suggests the containers are healthy and only the CLI's detection/recovery logic is failing.

Environment

• OS: Windows
• Docker Desktop: 4.81.0
• Supabase CLI: 2.109.1

Additional information

The database container exits with status 137 after Docker Desktop shuts down, but can be started manually without errors:

docker start supabase_db_<project>

The issue appears to be that supabase start detects an existing project but does not attempt to restart stopped containers.

[Harshabsavanur]

docker ps -a
docker rm <container_id>
docker volume ls
docker network ls
docker volume rm <volume_name>
docker network rm <network_name>
supabase stop
supabase start
supabase --version
npm install -g supabase

[gonzoblasco]

I ran into this too after a Docker Desktop restart. The issue is in how supabase start checks whether the project is already running — it likely checks for the existence of the containers (or the project directory marker) rather than checking their actual running state.

Looking at the CLI source, the check probably looks something like docker container inspect supabase_db_<project> and considers any response (including an Exited state) as "running". The fix would be to check the container state and, if all containers are stopped, either restart them or fall through to the normal start flow.

The workaround for now (as noted) is:

npx supabase stop --force
npx supabase start

Or starting the containers manually:

docker start $(docker ps -aq --filter "name=supabase_")

A cleaner UX would be: if supabase start detects existing containers but they are all stopped, it should restart them instead of reporting "already running".

[pascalarth-max]

Thanks for the clear repro. I've located the bug in \supabase/cli\ at \�pps/cli-go/internal/utils/misc.go\ — \AssertServiceIsRunning\ only checks that the container exists via \ContainerInspect, not that it's actually \State.Running. So a container in \Exited\ state passes the check and \supabase start\ falls into the \is already running\ branch instead of starting the containers. The maintainer comment from @gonzoblasco points at the same root cause.

I have a fix ready on a branch in https://github.com/pascalarth-max/cli (off \develop) that adds a
esp.State.Running\ check to \AssertServiceIsRunning, returning \ErrNotRunning\ when the container is exited/created/dead so the normal start flow takes over. It follows the same pattern already used in \internal/status/status.go:150.

Could a maintainer please add the \open-for-contribution\ label so the Contribution Gate allows the PR through? Happy to address review feedback on the branch.

Ref: #5917 in \supabase/supabase\ (filed here); fix targets \supabase/cli.

[Hallidayo]

Transferred from supabase/supabase repo.