Skip to content

Add Dockerfile for Supabase MCP server#197

Open
vivenstrix wants to merge 1 commit intosupabase-community:mainfrom
vivenstrix:add-dockerfile
Open

Add Dockerfile for Supabase MCP server#197
vivenstrix wants to merge 1 commit intosupabase-community:mainfrom
vivenstrix:add-dockerfile

Conversation

@vivenstrix
Copy link
Copy Markdown

Summary

Adds a Dockerfile to allow running the Supabase MCP server via Docker.

Why

This enables:

  • Easier local usage
  • Compatibility with Docker-based MCP registries
  • Consistent runtime setup for users and tooling

Notes

  • Uses Node 20 slim
  • Builds @supabase/mcp-utils and @supabase/mcp-server-supabase
  • Runs via stdio transport (MCP-compatible)

No breaking changes.

@Rodriguespn
Copy link
Copy Markdown
Contributor

Thanks for submitting this PR, @vivenstrix — we appreciate it!

Could you share a bit more about your use case for running a local MCP server via Docker instead of using our remote MCP option (https://mcp.supabase.com/mcp)?

Understanding the motivation would help us evaluate the change more effectively.

For reference, our documentation on setting up the remote MCP server is available here:
https://supabase.com/docs/guides/getting-started/mcp#remote-mcp-installation

@vivenstrix
Copy link
Copy Markdown
Author

vivenstrix commented Dec 26, 2025

Hey Pedro,

One of the main reasons I went down this path is that when I was looking for the Supabase MCP server in Docker MCP server catalogs / registries, it wasn’t there. Since I use Supabase heavily across a lot of my projects (backend APIs, Postgres, auth/OAuth, etc.), I wanted a clean and consistent way to expose those capabilities to my tooling.

More specifically, my goal is to have a single MCP server configured in Cursor — the Docker-based MCP server — and then let that server provide access to the tools it exposes (like Supabase) behind the scenes. That way I don’t have to register multiple MCP servers directly in the editor.

This helps with a couple of things in practice, avoids overloading Cursor with many MCP servers at once, keeps the context window smaller and more focused. Makes the setup more modular, especially when working with multiple backends, fits better with Docker-based MCP registries and workflows.
I’m not trying to replace or compete with the remote MCP option — that’s still a great default. This is more about enabling a local / containerized option for people who want tighter control over how MCP servers are composed and exposed to their editor.

Hope that helps clarify the use case

@vivenstrix
Copy link
Copy Markdown
Author

vivenstrix commented Jan 7, 2026

@Rodriguespn Just wanted to follow up and see if this would be approved or denied?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants