Supabase CLI 2.122.0 prunes local Docker network before database container creation on Windows/WSL2
Los mantenedores suelen responder en 1 día
@jgoux ya está trabajando en esto.
Desde el 27/10/2026.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 42/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- docker, postgresql, typescript
Línea de trabajo
Start by locating the supabase start flow and Docker network creation, cleanup, and database container startup paths; compare them with the related issue #6136. Determine whether the project-filtered prune request comes from CLI cleanup or overlapping processes, then identify a reproducible way to preserve the network through startup. Done means the database container attaches and the local stack starts without the network being pruned.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Affected area
Local development
Supabase CLI version
v2.122.0
Operating system
Windows 10 Pro 22H2 (Build 19045.7807), WSL2 3.0.1.0
Installation method
GitHub release binary
Command
supabase start
Actual output
Local Supabase startup failed because the project's Docker network was removed before the database container started.
Error:
network supabase_network_<local-project-id> not found
Docker API event timeline (UTC, October 26, 2026):
- 23:58:32.881 — Project network created
- 23:58:33.231 — Database volume created
- 23:58:35.587 — POST /v1.56/networks/prune, filtered by the local Supabase project label
- 23:58:36.634 — Project network destroyed
- 23:58:37.029 — Database container created referencing the deleted network
Docker API user agent: Docker-Client/29.9.2 (windows).
The Docker Engine did not restart. No application SQL or migrations were executed. The process responsible for the prune request has not been conclusively identified.
Expected behavior
The Supabase CLI should preserve the project's Docker network while creating and starting the PostgreSQL, Auth, and PostgREST containers.
The database container should attach successfully to the project network, and the local stack should start without an unexpected project-network deletion.
Steps to reproduce
- Install Supabase CLI 2.122.0 on Windows 10 with Docker Desktop using the WSL2 backend.
- Initialize a fresh isolated local project using
supabase init. - Configure local-only URLs, the
publicData API schema, and disable automatic migrations and seed execution. - Confirm Docker Desktop is running with the
desktop-linuxcontext. - Run
supabase start. - Observe the Docker network and container lifecycle events.
Observed: the project network was created and then pruned before the database container started.
This occurred during one observed startup attempt. Reproduction across repeated attempts has not been established.
Crash report ID
No response
Docker and service versions
Docker Desktop: 4.97.0 (244584)
Docker Client: 29.9.2
Docker Engine: 29.9.2
Docker API: 1.56
Docker context: desktop-linux
Server OS/Architecture: linux/amd64
containerd: 2.4.2
runc: 1.5.2
WSL version: 3.0.1.0
WSL default version: 2
Supabase CLI: 2.122.0
Local Supabase services did not become healthy. PostgreSQL, Auth, and PostgREST were not started successfully.
Additional context
The failure appears to involve a project-filtered Docker network-prune request occurring during startup.
The exact calling process is unknown. The timing is consistent with a Supabase CLI cleanup path or overlapping CLI processes, but neither is confirmed.
No Docker Engine restart, custom firewall configuration, or unrelated scheduled network-pruning service was identified.
Related issue: https://github.com/supabase/cli/issues/6136
That issue differs because PostgreSQL became healthy before cleanup. In this case, the project network was destroyed before database container startup.
No hosted Supabase project, production database, credentials, or customer records were involved.
Please advise whether this is a known cleanup-order/concurrency issue and whether an officially supported workaround or patched release is available.
- Lenguaje dominante
- TypeScript
- Estrellas
- 2.4k
- Forks
- 540
- Merge medio
- 17 h 29 min
- PR fusionados (30 d)
- 387
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de supabase/cli
-
db schema declarative sync: no way to fail (non-zero exit) when the generated migration is destructiveQuizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abierto✨ Feature supabase/cli
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
`supabase start` waits about 10 seconds for Docker's first health check after services are readyAbierto🐛 Bug supabase/cli
Dificultad 3/5 1-2 días Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
🐛 Bug supabase/cli
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Los mantenedores suelen responder en 1 día
-
stack: every Edge Function request starts a new worker, so the same function never reuses one and each call pays a cold startPosiblemente ocupada @7ttp la tomó hace 4 días. Abierto🐛 Bug supabase/cli
Dificultad 3/5 1-2 días Aptitud para principiantes 58/100
supabase/cli#7274 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
🐛 Bug supabase/cli
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
supabase/cli#7269 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de supabase/cli
Issues similares
-
guards: accept readonly arrays (and other array-likes) in isEmpty / hasElements / safeLengthAbiertoenhancement tech debt
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
danielmiessler/LifeOS#2533 ·
Los mantenedores suelen responder en 9 días
-
auto:producer auto:uiux
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
fritzprix/libr-agent#2447 ·
Los mantenedores suelen responder en 1 día
-
bug low priority
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100