DEV Community: anehme

Should You Really Run MCP Servers on Your Own Machine?

anehme — Tue, 29 Sep 2026 21:20:03 +0000

Running an MCP server directly on your machine is probably the easiest way to get started. Install the package, start the process, connect your client, and you're ready. For development and experimentation, there is nothing wrong with that.

The situation becomes less convenient as you add more servers. One might require Node.js, another Python, another a specific system package, and several may need their own environment variables or credentials. Eventually your local machine starts carrying the runtime requirements of every MCP server you want to try.

That made me wonder whether installing MCP servers directly on the host should really be the default beyond development. For many servers, running them in Docker is an interesting alternative.

Running MCP Servers in Docker

Putting an MCP server in a container gives it a defined runtime environment. Its dependencies and runtime versions stay with the container rather than becoming part of the host machine.

This is particularly useful when different MCP servers have completely different requirements. Instead of maintaining all those runtimes locally, each server can bring the environment it expects. The server also becomes something you can start, stop, replace, and recreate without treating the host as part of its installation.

Docker isn't automatically a security boundary, and containerizing an MCP server doesn't solve every operational problem. But from a runtime-management perspective, it gives you a useful unit to work with.

The interesting part starts when you have more than a few of those units.

What Happens When You Have Ten MCP Servers?

One container is easy to manage manually. Ten starts to look different.

You may have MCP servers for source control, databases, documentation, internal APIs, browser automation, and development tooling. Each can have its own image, configuration, credentials, runtime requirements, and lifecycle.

At that point, the question is no longer simply how to run an MCP server. You need to know which servers exist, which ones are running, how they should be configured, how clients reach them, and what happens when one stops.

Docker gives you a way to run the containers, but it doesn't understand the MCP-specific relationship between them. It doesn't know that one container represents a particular MCP server, which clients should use it, or how an MCP request should reach it.

This is where organizing and orchestrating MCP servers becomes a separate problem.

Organizing MCP Servers

Before orchestrating anything, you need some representation of what you are managing. An MCP server has an identity, a way to run, configuration, potentially credentials, and some way for clients to reach it.

Once that information is managed centrally, MCP servers stop looking like unrelated commands running on a machine. They start looking more like infrastructure.

Orchestration is the next step. Something has to translate that information into actions: start a server, stop it, create its container, connect to an existing instance, recover from a failure, or route a client to the right place.

This distinction is useful because Docker only handles part of the problem. Docker understands containers; the layer above it needs to understand MCP servers.

Where Does an MCP Gateway Fit?

Once servers are managed centrally, it becomes inconvenient for every MCP client to know where every individual server is running. A gateway gives clients a common entry point and can route MCP traffic to the appropriate server.

The gateway may also become a natural place for concerns such as identity, authorization, and session handling.

Figure 1: A gateway can gradually become responsible for more than routing MCP requests.

There is a catch. Once you have a central gateway, it is tempting to make it responsible for starting the servers as well. If those servers run in Docker, the gateway now needs access to Docker. If servers require credentials, credential handling can end up there too.

Eventually the gateway isn't only routing MCP traffic. It is also becoming the execution environment.

That can be a reasonable design for a small system, but it isn't the only option.

Separating Management from Execution

Another approach is to separate the component that understands the MCP environment from the component responsible for running it.

The gateway can handle the control side of the system: requests, routing, identity, authorization, and deciding which MCP server should receive an operation. A runner or broker can handle the execution side: starting processes, creating containers, connecting to running servers, and dealing with their lifecycle.

Figure 2: MCP management and execution can be treated as separate responsibilities.

The useful part of this design isn't simply adding another component. It is that the gateway doesn't necessarily need every capability required to execute every MCP server.

Docker is a good example.

Who Should Talk to Docker?

If your MCP infrastructure dynamically creates containers, some component needs access to Docker. Giving that access directly to the gateway is certainly possible, but another design is to keep Docker interaction in the execution layer.

Figure 3: Container management can sit behind the component responsible for MCP routing.

This doesn't mean the execution layer is automatically secure. Docker access can itself be highly privileged, so whichever component receives that capability still needs to be treated accordingly.

The benefit is simply that the network-facing gateway doesn't need Docker access just because some MCP servers happen to run in containers. Each component can receive the capabilities needed for its particular job.

Credentials Have a Similar Problem

The same question appears when MCP servers require credentials. A GitHub MCP server might need a token, while another server might need database or cloud credentials.

The component deciding whether a user can call a tool doesn't necessarily need to be the same component that supplies the runtime credential required by that tool.

Figure 4: Authorization and runtime credential handling can happen at different layers.

How credentials should actually be provided depends on the system. They might be environment variables, mounted files, short-lived credentials, or something else. The useful architectural question comes before choosing a mechanism: which components actually need access to the credential?

Reducing the number of components that need a secret makes the credential path easier to reason about.

From Running MCP to Orchestrating MCP

So, should you run MCP servers on your local PC? For development, probably. It's simple and there is little reason to introduce infrastructure before you need it.

Docker becomes interesting when you want cleaner runtime environments or don't want every MCP server's dependencies installed directly on the host. Once you start running several containerized MCP servers, however, Docker itself is no longer the interesting problem. You need a way to organize those servers, manage their configuration and lifecycle, and route clients to them.

That's the problem I've been exploring with MCPlama: what happens when MCP servers are treated as infrastructure that can be organized and orchestrated rather than as individual commands someone manually keeps running.

The progression is fairly natural: you start by running an MCP server locally, move it into a container when isolation and runtime management become useful, and eventually need an orchestration layer when the number of servers grows.

At that point, the question has changed from “How do I run this MCP server?” to “How do I manage all of them?”

MCPlama is open source: https://github.com/mcplama/mcplama

MCP is easy to start with. Running it for a team is a different story.

anehme — Wed, 23 Sep 2026 20:44:35 +0000

I've been experimenting with MCP for a while, and one of the things I like about it is how easy it is to get started. You find an MCP server, add it to Claude, Cursor, VS Code, or another compatible client, configure the credentials it needs, and you're basically done.

For a developer working locally, this model makes a lot of sense.

But while working with more MCP servers, I started wondering what this setup looks like when you move beyond a single developer.

Let's say a team has 10 developers. Some use Claude Code, some use Cursor, and others use VS Code. The team also has MCP servers for GitHub, databases, internal APIs, monitoring, and maybe a few tools they built themselves.

The simple architecture starts becoming something like this:

Technically, there's nothing wrong with this. Every developer can configure the MCP servers they need and continue working.

The problem is that you now have configuration, credentials, and access distributed across multiple machines. At that point, managing MCP starts looking less like configuring a developer tool and more like managing infrastructure.

Credentials become surprisingly important

Credentials were the first thing that made me think about this problem.

Suppose you have an MCP server that connects to an internal API. When you're the only person using it, keeping the credentials locally is simple enough. But if 20 developers need access to that same service, you have to decide how those credentials should be managed.

You could distribute the same credentials to everyone, but then they're stored across many developer machines. You could create separate credentials for every developer, which is better for isolation but creates more administrative work.

Then normal lifecycle problems start appearing. Someone leaves the company, an API key needs to be rotated, a developer changes teams, or an MCP server moves somewhere else.

None of this is unique to MCP. We've already dealt with the same problems with databases, internal APIs, cloud infrastructure, and CI/CD systems.

The interesting part is that MCP is starting to expose those same infrastructure problems in a new place.

Access control is another problem

Once multiple people use the same MCP infrastructure, authentication alone isn't enough.

You also need to decide what each person should be allowed to use.

For example, maybe everyone on the engineering team should be able to use an MCP server that searches GitHub. At the same time, you might have another MCP server connected to production infrastructure that should only be available to a smaller group.

It can get even more granular than that. A user might be allowed to call read-only tools while another user can call tools that modify data.

With a local MCP configuration, the MCP client generally connects directly to the server:

That simplicity is great, but it also means there isn't necessarily a central place to make these decisions.

Auditing gets more interesting when AI is involved

Another question I hadn't thought much about initially was auditing.

If an AI assistant uses an MCP server to interact with GitHub, a database, an internal API, or some other company system, at some point you may want to understand what happened.

For example:

In a company environment, it can be useful to know which user initiated the interaction, which MCP server was used, which tool was called, and when it happened.

Again, this isn't particularly exciting infrastructure. Logging and auditing rarely are. But these are usually the boring problems that start becoming important once something moves from experimentation into regular use.

This started reminding me of API gateways

The more I thought about it, the more the problem reminded me of how APIs evolved.

A simple application can connect directly to an API:

Client → API

As systems become larger, we often introduce another layer:

Client → API Gateway → Services

The gateway gives us a central place for things like authentication, authorization, routing, policies, and logging.

That made me wonder whether MCP might eventually need a similar pattern.

Instead of every client knowing how to connect to every MCP server, clients could connect through a common layer.

Credentials could be managed centrally. Access decisions could happen in one place. The underlying MCP servers could also move or change without requiring every developer to update their configuration.

Of course, this adds complexity. If you're one developer running two MCP servers on your laptop, introducing a gateway would probably make your setup worse rather than better.

But for a team sharing MCP infrastructure, I think the tradeoff becomes more interesting.

I decided to build the idea and see what happens

At some point I realized I could keep thinking about the architecture or actually build it and discover where it breaks.

So I started an open-source project called MCPlama.

[https://mcplama.com]

MCPlama is my attempt at the gateway/control-plane approach. MCP clients connect through it, while the platform handles the infrastructure around the MCP servers.

The basic architecture looks something like this:

The goal isn't to change MCP itself. Clients and servers still communicate using MCP. The gateway provides a place to manage the parts around that communication: identity, credentials, policies, routing, and auditing.

One design decision I spent some time thinking about was where the MCP servers themselves should run.

Putting everything inside the gateway would make deployment easier, but I wasn't comfortable with the idea of arbitrary MCP servers sharing the same process and environment as the control plane.

Instead, I started separating the management side from the execution side.

That introduces additional infrastructure, but it also creates a clearer boundary between managing MCP servers and actually executing them.

How are teams actually managing MCP?

As adoption grows, I think the conversation around MCP will gradually shift from "How do I connect this server?" to "How do we actually manage all of this?"

That means figuring out how teams share MCP servers, where credentials should live, how permissions should work, how private servers are deployed, and how organizations keep track of what their AI clients are doing.

I'm curious how teams using MCP today are approaching these problems. Are developers still configuring everything individually? Have you built some shared infrastructure around it? Or are you using MCP across a team and haven't run into these problems at all yet?

I'd genuinely like to hear how others are solving this.