Does the Supabase MCP Work Offline or Locally?

Supabase MCP itself always needs a live connection to Supabase's hosted API — it has no offline mode. Running Supabase MCP offline in the strict sense isn't possible, since its tools call the same personal-access-token-gated API as the web dashboard. What does work locally is Supabase's own CLI and Docker stack, paired with PostgreSQL MCP pointed at the local database instead of Supabase MCP's cloud tools. That combination covers schema and data work without internet, but migrations tracking, logs and advisors stay cloud-only.

What does “offline” mean for a cloud-based MCP server?

An MCP server only qualifies as offline-capable if the tool calls it exposes can complete without a network round trip. Supabase MCP's tools — list_tables, apply_migration, execute_sql, deploy_edge_function, get_logs, get_advisors, list_extensions, list_migrations and generate_typescript_types — all go through Supabase's hosted platform API. Its own description explains that the server authenticates with a personal access token rather than a project anon key, and that this means anything you can do as the project owner, the agent can do too. A personal access token is a hosted-API credential, so every one of those calls is a network call by design.

That design choice is what makes questions about running Supabase MCP offline different from the usual “does this MCP run locally” question. Plenty of MCP servers run as a local process on your machine while still calling a remote API underneath — the process running locally doesn't make the underlying service offline-capable. Supabase MCP is a clear example: the server binary can run anywhere, but the tools it exposes are shaped entirely around a hosted project reference, so there's no local substitute for the API they call, even with Docker running a full Supabase stack next to it.

That split between where the process runs and what it talks to matters for any database-flavored MCP server, not just Supabase's. The same distinction shows up when comparing self-hosted and vendor-hosted MCP setups more broadly — see Local vs Remote MCP Servers: What Changes for how that plays out beyond databases. For Supabase specifically, the practical answer is to separate the MCP server from the Postgres database it manages, because only the second half has an offline story at all.

What can the MCP do with Supabase's local CLI and Docker stack?

Supabase's own documentation describes a local development workflow built on the Supabase CLI plus a container runtime, with Docker Desktop listed as the preferred option alongside Rancher Desktop, Podman and OrbStack. The documented quickstart is three commands, run from your project:

• npm install supabase --save-dev — adds the CLI as a dev dependency
• npx supabase init — scaffolds a local Supabase project
• npx supabase start — brings up the full stack in Docker containers

Once it's running, the documentation points you at the local Studio UI on http://localhost:54323 to browse the same tables, auth users and storage buckets you'd see on the hosted dashboard.

What Supabase MCP itself can do with that local stack is, by its own description, nothing directly. Its tools are wired to the hosted API through a personal access token and a project reference, not to an arbitrary Postgres connection string, so there is no documented setting that redirects list_tables or apply_migration at a local instance instead of the hosted one. The local stack is real, and it's Supabase's own product for developing without touching a hosted project — it just isn't something the MCP server's own tool set knows how to target.

That's not a knock on the local stack — it's aimed at a different job than the MCP server is. If your workflow already leans on supabase start for local iteration, the step-by-step setup for pointing an agent at the hosted side once you're back online is covered in How to Use Supabase MCP with Claude Code. The practical bridge for working entirely offline, covered next, is to point a different, connection-string-based MCP server at that same local Postgres instance instead of waiting for Supabase MCP to grow a local-targeting option.

What doesn't work without an internet connection?

Everything that makes Supabase MCP more than a database connector needs the network. get_logs and get_advisors pull from the hosted project's log and advisor pipelines, and neither has a local equivalent in the server's description. deploy_edge_function ships code to Supabase's hosted Edge Functions runtime — and per the server's own pitfalls, MCP-driven deploys skip the local CLI's import map resolution, so relative-URL or non-jsr dependencies get silently stripped on deploy. That's a reason to run supabase functions serve first regardless of whether you're online, since the failure mode is silent either way.

apply_migration and execute_sql both write to a project, and the server's pitfalls describe them as different code paths: migrations get versioned and tracked, raw SQL doesn't, so using execute_sql for schema changes makes the migration history drift and db diff misbehave. That's a hosted-project concern independent of connectivity, but it means there's no offline-friendly way to skip the distinction. generate_typescript_types regenerates the Database type from whichever schema the token can reach, which again defaults to the hosted schema unless something else has separately wired up a local one.

Running Supabase MCP offline, in other words, would mean losing logs, advisors, edge function deploys and migration tracking all at once — the exact platform surface its description says makes it far more capable than the bare Postgres MCP. Offline work has to trade that surface away and fall back to plain database access, which is where a smaller, connection-string-based server becomes useful instead of a limitation.

Can you combine local Supabase with Postgres MCP for real offline work?

In practice, yes — by splitting the job between two servers instead of asking one to do both. Run supabase start locally, then point a connection-string-based server at that local Postgres rather than at Supabase MCP's cloud tools. PostgreSQL MCP is built for exactly this: its description says it works with any Postgres, and it exposes only query, list_schemas, list_tables and describe_table. A connection string is the only thing it needs, and a local Supabase Postgres instance is still a connection string — its documented format is postgresql://user:password@host:5432/dbname, with your local host and credentials swapped in.

This split plays to each server's strengths. Postgres MCP's description notes it has the lowest token cost of any database MCP in the catalogue, and its four-tool surface suits ad-hoc schema exploration and queries against a local database with no advisors or edge functions to worry about. The connection-security caveat from its own pitfalls still applies locally, though: a role with full DDL rights lets an agent drop tables just as easily on a local Docker Postgres as on a hosted one, so setting up a read-only role for exploration is worth doing either way. Setup steps are in How to Use PostgreSQL MCP with Claude Code.

What this combination gives up is everything that made Supabase MCP worth reaching for in the first place — its description lists auth, storage, realtime, edge functions and advisors as the platform surface Postgres MCP doesn't touch. The recipe Auto DB Migrations on Push assumes a hosted project with Supabase MCP's own migration tooling in the loop; a fully offline setup would need to replace that step with local supabase CLI commands and reconcile the two migration histories once you're back online.

Use cases: coding on a plane, air-gapped environments

The clearest case for this split is working with no connectivity at all — on a flight, in a restricted or air-gapped network, or just on a connection too slow to want an agent burning API calls against a hosted project. Supabase's local stack wasn't built specifically for offline AI agent use, but the pieces line up: supabase init and supabase start bring up a full local Postgres, Auth and Storage stack in Docker with no dependency on any hosted project, which is exactly the environment an air-gapped setup needs.

For an agent-driven workflow in that setting, wanting “Supabase MCP offline” access usually really means wanting schema and data operations to keep working, and that's the part PostgreSQL MCP handles once it's pointed at the local instance. Anything that depends on the hosted project specifically — advisors, the logs pipeline, edge function deploys — simply has to wait for connectivity, since neither server describes an offline substitute for those.

If the machine running the local stack is ever on an untrusted public network, Supabase's documentation recommends creating a separate Docker network and binding to 127.0.0.1 before starting it, rather than exposing the stack's ports broadly. That's worth doing regardless of whether an agent is involved, since the local stack carries the same admin-level access model Supabase MCP's own pitfalls describe for the hosted personal access token — full project rights, no read-only mode — just running on your laptop instead of in the cloud.

FAQ

Does Supabase MCP have a documented local or offline mode?

No documented one. Its description ties every tool to a personal access token authenticating against Supabase's hosted API, and none of the pitfalls or tool descriptions mention an offline mode or a setting for pointing the server at a local Postgres connection string instead. The server's local stack and the MCP server are separate pieces of tooling from Supabase, and only the CLI-based stack is described as running fully on your own machine.

Is running the MCP server process locally the same as offline?

No — running the server binary on your own laptop only changes where the process lives, not what it talks to. Supabase MCP's tools still call the hosted API over the network regardless of where the server itself runs, the same way a locally-run process for any cloud service still needs connectivity. Only the underlying Postgres, Auth and Storage stack that supabase start brings up is actually offline-capable.

Which MCP server should I use to query a local Supabase database?

PostgreSQL MCP, according to its own description, since it works with any Postgres via a plain connection string and doesn't require the hosted-project reference Supabase MCP needs. It won't give you migrations tracking, advisors or edge function deploys — those stay tied to Supabase MCP and the hosted project — but for schema inspection and queries against a local database, its four-tool surface is the documented fit.