Local development

The Supabase CLI runs several local projects on one machine, one per git worktree. Each coding agent gets its own Postgres, Storage, Edge Functions, and MCP server. Projects start in seconds. In our Linux benchmark, nine idle projects fit in the memory one used to take because only the services you use are running. In sandboxes and CI runners that have no container engine, the native runtime runs every Supabase service as a plain process at the same pinned versions as the Docker images.

Key features

1. One project per worktree: The CLI picks and remembers ports for each project. Agents stop coordinating project IDs by hand.
2. Isolated data: Reset one project's database while another is mid test run. Schema changes, resets, and Storage uploads never cross over.
3. Services start on demand: Postgres comes up first and everything else wakes on its first request. Pass --eager to start everything up front.
4. Native runtime: Run without Docker or Podman on Linux (amd64 and arm64 with glibc 2.35 or later) and macOS 14 or later on Apple silicon. The CLI downloads and verifies the service archives on first start and picks the native runtime when no container engine responds. Use Docker or Podman for several projects on one machine. The native runtime is intended for one project per sandbox or CI runner.
5. Per-project MCP server: Each local project serves its own /mcp endpoint. An agent only sees the database it's working on.

When to use it

• Several coding agents working on the same app in parallel
• Hosted sandboxes and CI runners with no Docker daemon
• Laptops where the default stack is too heavy to run more than once

Update to CLI v2.119.0 or later, then turn it on with SUPABASE_EXPERIMENTAL_STACK=1 supabase init for a new app. For an existing app, add stack = true under [experimental] in supabase/config.toml and remove the fixed ports from it before the first start. Read the multiple local projects guide and the Docker and native runtimes guide.