MCP Server Hosting: Hosted vs Self-Hosted vs Local

The short answer

There are three practical MCP server hosting models: a local server on the user's machine, a remote server your team self-hosts, and a managed hosted service operated by a provider.

Choose a local MCP server when one trusted user needs a narrow capability on one machine, local execution is valuable, and that user can safely manage the runtime and credentials.

Choose a hosted MCP server when multiple users or AI clients need the same capability, access must work beyond one laptop, or authentication, updates, monitoring, revocation, and availability need a clear operational owner.

Neither model is automatically more secure or less expensive.

A local server reduces the remote network surface, but it executes code with access to the user's machine and often stores backend credentials locally. A hosted server keeps runtime and backend credentials off developer machines, but introduces an internet-facing service, an operator trust boundary, and ongoing hosting responsibilities.

The right comparison is not “free local package versus paid cloud URL.” It is who operates the server, where secrets live, which failures matter, and how many people must use it.

Local, remote, hosted, and self-hosted are different terms

MCP defines the protocol, not one deployment model. The official MCP architecture overview describes servers as programs that can run locally or remotely.

In common usage:

• Local MCP server: runs on the same machine as the AI client, usually as a subprocess over stdio
• Remote MCP server: runs independently and is reached over a network transport, normally Streamable HTTP
• Hosted MCP server: a remote server operated for you by a provider or internal platform team
• Self-hosted MCP server: a local or remote deployment that your organization builds or operates itself

This means “hosted versus local” compares both location and operational ownership. A server can also be remote and self-hosted: your team deploys it to its own cloud account and owns the complete production lifecycle.

datamcp is a hosted service. It provides remote MCP endpoints for PostgreSQL and OpenAPI connections. A self-hosted or on-premise datamcp edition is not currently available.

MCP server hosting options at a glance

“Remote” describes where the MCP server runs relative to the client. “Self-hosted” and “managed” describe who owns its deployment and operations. A remote MCP server can therefore be either self-hosted or managed.

Local vs managed hosted MCP at a glance

How the transport changes the operating model

The MCP transport specification defines two standard transports: stdio and Streamable HTTP.

Local stdio

With stdio, the MCP client launches the server as a subprocess. JSON-RPC messages travel through standard input and output.

AI client → local subprocess → filesystem, CLI, or backend

There is no separate HTTP endpoint to expose or authenticate. The client controls process startup and termination, and the server can read environment variables or use credentials available on the machine.

That simplicity is valuable for local files, developer tools, disposable environments, and capabilities that should remain physically close to the user.

It also means the installed server is code executing with the privileges granted by the operating system and AI client. The MCP security guidance highlights malicious startup commands, arbitrary code execution, local data access, and package supply-chain risk as threats that local-server users must evaluate.

Hosted Streamable HTTP

With Streamable HTTP, the MCP server runs as an independent service and accepts requests at an HTTP endpoint.

AI client → authenticated HTTPS endpoint → tools → backend

This model supports shared access and centralized operations, but the operator must handle HTTPS, authentication, origin validation, token verification, request limits, monitoring, and deployment.

The protocol can carry the same tool semantics in either model. The difference is the transport boundary and the operational system around it.

Security: compare threat models, not labels

“Local is safer because data stays local” and “hosted is safer because credentials stay off laptops” can both be true in specific architectures. Neither statement is universally true.

Local-server security advantages

• no public MCP endpoint is required for stdio
• traffic between client and server does not cross a network transport
• a local-only backend can remain inaccessible from the internet
• the user can inspect, pin, sandbox, and control the exact server build
• offline workflows are possible when all dependencies are local

Local-server security responsibilities

• review every package, binary, Docker image, and startup command
• restrict filesystem, process, and network access
• avoid running the client or server with administrator privileges
• protect secrets stored in .env, shell profiles, keychains, or client configuration
• update every machine when a vulnerability is fixed
• remove stale configurations when a teammate leaves or changes projects

The local process is not automatically sandboxed by MCP. Its practical access depends on the host application, operating system, package, and configuration.

Hosted-server security advantages

• backend credentials can remain behind the server boundary
• one authentication and revocation layer can serve many clients
• updates and security fixes can be deployed centrally
• access events can be recorded in one activity history
• developer machines can receive scoped MCP credentials instead of database passwords

Hosted-server security responsibilities

• protect an internet-reachable endpoint with HTTPS and authentication
• validate tokens on every protected request
• isolate tenants, users, sessions, and backend credentials
• restrict outbound requests and defend against SSRF where relevant
• monitor abuse, failures, and unusual access patterns
• document retention, deletion, incident response, and credential rotation
• evaluate what the operator can access and what evidence supports its claims

Hosted architecture moves responsibility; it does not eliminate it. A managed provider takes on part of the control plane, while the customer still owns backend permissions, data classification, client approval behavior, and appropriate use.

Credentials and revocation

Credentials are often the decisive architectural difference.

Local pattern

A local server commonly receives a database URL or API key through environment variables:

AI client config → local MCP process → backend credential → production system

For one trusted developer, this may be acceptable. For a team, the same pattern can distribute powerful backend credentials to many machines. Offboarding or reducing access may require rotating the shared credential and updating every remaining client.

Hosted pattern

A hosted server can separate client identity from backend identity:

AI client credential → hosted MCP policy → stored backend credential

That allows one client token or link to be revoked without replacing the backend credential for every other user. The implementation must still encrypt secrets appropriately, restrict internal access, and avoid token passthrough between unrelated trust boundaries.

For remote HTTP MCP, the official authorization guidance follows OAuth 2.1 conventions. Local stdio servers generally retrieve credentials through their environment or another local mechanism instead.

Total cost: include engineering and operations

A local open-source server may have a software price of zero. That does not make its total cost zero.

Estimate all of these components:

For one developer, a local server can be dramatically cheaper and faster.

For twenty developers, the recurring cost of installation support, configuration drift, secret rotation, access reviews, broken upgrades, and fragmented logs can exceed the subscription price of a managed service.

Do not compare only the monthly invoice. Compare the hours required from application engineering, platform engineering, security, and support.

Latency, reliability, and offline access

Local latency

stdio avoids a network hop between the AI client and MCP server. For filesystem, shell, or local-development tools, this can be the fastest and most resilient arrangement.

If the local server still calls a remote database or SaaS API, however, most request latency remains in the backend network path. Moving only the MCP process onto the laptop does not make the remote backend local.

Hosted latency

A hosted endpoint adds network transport between client and MCP server. Its real impact depends on geography, backend location, connection reuse, tool workload, and response size.

Hosted architecture can improve reliability for teams because one continuously operated service replaces many laptop-specific processes. It also introduces service availability and internet connectivity as dependencies.

Offline operation

Choose local when the workflow must keep working without internet access and its data or tools are available locally. A hosted MCP service normally cannot satisfy that requirement.

Updates and configuration drift

Local MCP configuration is easy to start and easy to fragment.

Different teammates may have:

• different package versions
• different environment variables
• different tool permissions
• different startup flags
• stale backend credentials
• unreviewed changes copied from documentation or chat

A hosted deployment centralizes the server version and policy. Client configuration can still drift, but the execution layer has one release and one operational owner.

Self-hosting a remote server also centralizes the deployment, but your team owns compatibility testing, migrations, rollbacks, observability, and protocol upgrades.

Team access and auditability

Local servers fit personal workflows. Team workflows need identity.

Ask whether you can answer:

• which user connected the AI client
• which server and version executed the tool
• which backend credential was used
• which permission policy allowed the operation
• whether the request succeeded or was denied
• how one person's access can be removed without disrupting everyone else

If database logs only show one shared role, or every laptop uses the same API key, the team does not have meaningful MCP-level attribution.

A hosted service can centralize those signals, but only if the product actually implements user or link identity, permissions, activity records, and targeted revocation. Do not assume every remote MCP URL includes a control plane.

When local MCP is the better choice

Choose local when most of these are true:

• one trusted developer uses the server
• the capability targets local files, a CLI, or a development environment
• offline use matters
• no public endpoint should exist
• credentials are already controlled on that machine
• centralized audit history is unnecessary
• the team can review and pin the server package
• installing and updating the runtime is acceptable

A filesystem server is the clearest example: the useful resource is already on the machine, and moving that access to a hosted provider may create an unnecessary data path.

When hosted MCP is the better choice

Choose hosted when one or more of these are true:

• multiple users or AI clients need the same backend
• the capability must work from several machines or environments
• backend credentials should not reach developer laptops
• each user, project, or client needs a different access policy
• centralized revocation and activity history are required
• the endpoint must remain available when one laptop is offline
• your team does not want to operate OAuth, transport security, monitoring, and upgrades
• PostgreSQL or API access is already remote and production-facing

Hosted is particularly useful when the MCP server is only one piece of a larger access-control problem.

When remote self-hosting is the better choice

Operate your own remote MCP server when:

• you need custom tools or domain workflows a managed product does not expose
• the server must run inside your private network or cloud account
• you have platform engineering and on-call capacity
• you need complete control over deployment, telemetry, retention, and upgrades
• provider dependency is unacceptable
• your security model requires controls the available hosted services cannot verify

This option offers the most control and the most responsibility. Budget for the production system around the MCP handler, not only the handler itself.

What self-hosted MCP actually requires

The MCP request handler is only one part of a production deployment. Before choosing self-hosting, assign an owner and an implementation for each of these layers:

The MCP transport specification explicitly requires Streamable HTTP servers to validate the Origin header and recommends authentication for all connections. A cloud deployment without those controls is not production-ready merely because it has a public HTTPS URL.

A minimum deployment test

Before connecting production data, verify that the hosted endpoint can pass all of these tests:

1. An unauthenticated request is rejected.
2. An expired or revoked client credential is rejected.
3. A user cannot discover or call a tool outside the assigned policy.
4. Backend credentials never appear in MCP responses or client configuration.
5. A denied operation produces a safe, useful error without leaking secrets.
6. A deployment can be rolled back without losing the access-control state.
7. The on-call owner can identify the client, policy, tool, backend, and outcome for a failed request.

If the team cannot run this test repeatedly, a managed hosted service may have a lower total cost even when its monthly price is higher than the raw infrastructure bill.

Step-by-step decision framework

Step 1: Classify the capability and data

Identify whether the tools access local files, developer infrastructure, production databases, customer data, or external APIs. Record the maximum damage from an incorrect or compromised call.

Step 2: Count users, clients, and environments

One developer on one machine is a different system from twenty teammates using Cursor, Claude, ChatGPT, and VS Code across development and production. ChatGPT currently connects to remote MCP apps rather than a raw local database process; the ChatGPT PostgreSQL guide shows that hosted path and its workspace requirements.

Step 3: Draw the credential path

Write down where every client credential and backend credential is created, stored, transmitted, rotated, and revoked. Reject designs that rely on one powerful shared secret without attribution.

Step 4: Assign operational ownership

Name the owner for updates, vulnerability response, uptime, logs, backups, access reviews, and incidents. If no one owns those tasks, self-hosting does not make them disappear.

Step 5: Calculate total cost

Compare subscription or infrastructure costs with engineering time for setup, authentication, deployment, monitoring, support, upgrades, and offboarding.

Step 6: Run a bounded pilot

Start with one non-production or read-only connection. Test installation or remote authentication, tool discovery, expected denials, logging, credential rotation, and revocation.

Step 7: Choose per capability, not globally

You can use a local filesystem server and a hosted PostgreSQL server in the same AI client. MCP does not require every capability to share one deployment model.

How datamcp fits this comparison

datamcp is a hosted MCP service for PostgreSQL and OpenAPI 3.x sources. It is designed for remote backend access where teams need a stable endpoint and a managed control layer.

Current capabilities include:

• hosted remote MCP endpoints
• datamcp API key authentication and OAuth 2.0 with PKCE for compatible clients
• read-only, read-write, full-access, and custom MCP links
• PostgreSQL table-level operation policies
• server-side supported backend credential storage
• PostgreSQL query and denial activity logs, with CSV or JSON export of the visible activity page
• individual MCP link deletion and revocation

OpenAPI endpoint calls do not currently appear in the datamcp activity log. datamcp is not a local filesystem MCP server, a general container host for arbitrary MCP packages, or a self-hosted/on-premise product. It does not remove your responsibility for PostgreSQL roles, API-token scope, TLS configuration, data classification, client security, backups, or incident response.

Use the MCP gateway product page to review the managed control layer, or read the MCP proxy guide when you need to distinguish traffic forwarding from gateway policy. Compare the best MCP servers by workflow, apply the MCP security checklist to production controls, and review pricing against your expected operating cost.

For a database-specific decision, the database MCP server guide separates local SQL tools, provider servers, self-hosted remote deployments, and managed database gateways.

Final recommendation

Use local MCP for personal, machine-local, offline, and tightly trusted workflows.

Use hosted MCP when shared remote access, central credentials, consistent policy, revocation, and operations matter more than keeping the server process on each user's machine.

Use remote self-hosting when your requirements justify complete infrastructure ownership and your team is prepared to operate it.

The best architecture is often mixed: local servers for local capabilities, hosted or self-hosted remote servers for shared production systems, and different permissions for every trust boundary.