MCP Server Deployment Options – Which Mix Is Right For you?

MCP servers are primarily distributed using one of two methods: a remote HTTP-based connection to a third-party managed server or as a command you can run to start a server on a user’s workstation.

However, companies are looking for more secure and scalable ways to deploy MCP across their organization without requiring non-technical users to run terminal commands. That’s why many are actively using shared containers and other infrastructure they manage to create new deployment styles.

These deployment styles deviate sufficiently from the binary remote/local model to require their own categorization, coverage, and guidance.

To help organizations understand their full range of MCP deployment options, we (MCP Manager) have designated distinct categories of MCP server deployment:

  1. Remote Deployments: MCPs hosted externally by a third-party, which you connect to via a provided URL
  2. Managed Deployments: MCPs deployed within organization-managed infrastructure, or via a service like MCP Manager, with two clear subtypes:
    1. Managed-Dedicated: Each user/agent has their own container instance
    2. Managed-Shared: Users/agents access the same shared container instance
  3. Workstation Deployments: MCPs deployed locally on a user’s machine, which is only necessary if the MCP server requires access to programs or files on that specific workstation.

This guide provides a brief overview of the deployment types above, including example use cases, and key pros and cons for each.

MCP Deployment Styles In Detail

1: Remote Deployments

Approach: Remote MCPs are hosted entirely on external web servers. All you need to connect to a Remote MCP server is a URL, which you provide to your MCP client. You don’t need to install or run anything locally. The client connects to the server over HTTPS, and most remote servers provide authentication (typically using OAuth 2.1).

Rationale: Remote deployments are the fastest, easiest MCP server deployment type to get up and running, with minimal configuration and setup, and zero infrastructure overhead.

Remote deployments put the burdens of server management, updates, and resource costs onto the server provider instead of your organization. They make perfect sense for SaaS apps that require external connectivity.

Example:

MCPs for SaaS products (Salesforce, Jira, Asana, Stripe, etc.) and AI-agents embedded in browsers and web apps.

Pros:

  • Fast and easy to deploy
  • Scalability – one server can serve thousands of clients simultaneously
  • No local installation or configuration needed on user devices
  • Centralized updates and maintenance with immediate effect for all users
  • Standard web identity management methods (OAuth, HTTPS) are typically used and implemented by the server provider
  • Device agnostic
  • Low resource requirements

Cons:

  • Dependency on third-party hosting
  • Potential uptime/reliability issues that are outside your control
  • Reliant upon third-party for data/information security measures
  • Not suitable for use cases where local files or resources are required

2: Managed Deployments

Managed MCP server deployments take local MCP deployments and “package” them in a container, and deploy them to some form of cloud or on-premise hosting option, which is then accessible via a url. This approach allows you to share the server between multiple users, instead of being isolated to a single user’s machine (as in a fully-local “Workstation Deployment”).

Managed MCP deployments are the most flexible type; as they aim to straddle the gap between Remote and Workstation MCP server deployments, addressing the shortcomings of both.

The Managed approach overcomes many of the scalability challenges of Workstation MCP deployments, as it doesn’t require individual installations on each user’s machine.

Individual installations create ballooning support and training burdens for IT teams, and create additional security risks from attackers claiming to be from IT and directing technically-naive team members to run commands on their workstation.

However, Managed deployments add complexity and can prove difficult to set up, maintain, and scale.

There are two subtypes of Managed MCP server deployments:

A – Managed-Dedicated: Each agent/user gets their own containerized instance

B – Managed-Shared: A single containerized instance shared by multiple agents/users

2A: Managed Dedicated

Approach: Each person and/or AI agent gets their own instance of the MCP.

Rationale: Some MCP servers – or use cases for them – are unsuitable for shared use and can create conflicts, or become unusable if multiple users try to use them simultaneously.

Example:

Browser automation using Playwright or Puppeteer MCPs. It would be seriously chaotic if 30 developers tried to control the same browser session at once. Instead, in Managed-Dedicated deployments, each developer (or AI agent) gets their own containerized instance of a browser.

Pros:

  • Isolates users in their own environment to prevent interference and conflicts
  • Reproduce standardized environments using containers
  • Provides a more scalable option for MCP servers that need access to local files/resources

Cons:

  • Higher resource usage – one instance per user/agent
  • Requires significant orchestration to create, manage, update, and remove instances

2B: Managed-Shared

Approach: A single MCP instance runs in a container hosted on a cloud or on-premise server, accessible to many clients. All users share the same service.

Rationale: Some resources are better when centralized. Instead of 20 people re-creating the same knowledge or data store, you host it once and let everyone use it.

Example:

A Memory MCP where one person can add coding standards (e.g., “always end JavaScript code with a semicolon”), and every AI across the team can read from that knowledge base. Think: Shared libraries and knowledge hubs for humans and AI agents where Some users have “write” permissions; most will have “read-only” permissions.

Pros:

  • Lower administrative overheads – a single instance to manage and update
  • Reduces the likelihood of errant or outdated versions
  • Ideal for distributing shared guidelines/knowledge, and for aligning AI agents with policy at scale

Cons:

  • Enforcing permissions and security is more complex
  • Performance can lag if too many clients crowd the server
  • Conflicts are possible – even with a low number of users with “write” permissions

3: Workstation

Approach: Workstation deployments of MCP servers run directly on the user’s machine via command input, and communicate with MCP clients via STDIO.

It is possible to expose Workstation MCP servers to remote access via secure tunnels, without directly opening firewall ports, enabling authenticated, encrypted access to locally deployed MCP servers.

You can containerize an MCP to restrict its access to only those files/utilities you feel it needs. This requires extra work, but is far more secure than opening up all your local files – including sensitive data, API keys, and access tokens – to any locally deployed MCP server.

Rationale: Provides the MCP access to the local file systems, code editors, IDEs, or OS-based functionality that it needs.

Guide to deploying Workstation (Local) MCP servers securely

Examples:

  • Code Editor Integration: An MCP that augments VS Code or another editor by interacting with the open buffers and local extensions.
  • File Management Tools: An MCP that organizes your local project files, runs builds, or cleans temporary directories.
  • System Resources: Anything that must query local hardware (for instance, GPU/CPU stats) or system utilities (like git configured on your machine).

Pros:

  • No abstraction issues because the MCP interacts with the local environment without many/intervening layers
  • You/your organization controls deployments and their configuration

Cons:

  • Places the burden of containerization, proper token storage, and limiting access on the end-user/configuring user
  • Requires manual installation and configuration on each user’s machine where the MCP is required
  • Large-scale deployments require configuration management tools, and scripts/or package managers

Deploy All Your MCP Servers Easily and Securely

Use MCP Manager to make all your enterprise MCP server deployments simple, successful, and secure.

MCP Manager makes it easy to:

  • Run MCP servers using any configuration and deployment type
  • Enable non-technical teams to use AI agents and MCP connections
  • Manage, monitor, and optimize all your organization’s MCP operations
  • Get verbose end-to-end logs, and rich, enterprise-level observability
  • Protect your organization against AI and MCP-based security risks

To learn more, schedule your 1-1 consultation with us.

Ready to give MCP Manager a try?

Learn More

MCP Manager secures AI agent activity.