2026 MCP Server Self-Hosting: How to Deploy? New Stateless Notes

Your MCP tool works on your laptop, but teammates cannot use it without running your local setup.

This week, keep stdio for tools tied to your own machine; choose Streamable HTTP when a team needs a shared remote service. The MCP specification dated July 28, 2026, removes protocol-level initialization handshaking and session IDs, but your application still needs its own authorization, data handling, and durable business state.

This guide is for individual developers deciding whether to move a local MCP server, small teams sharing tools across clients, and technical leads planning protocol upgrades and compatibility checks.

Last updated October 25, 2026. Protocol behavior and migration guidance were checked against the MCP specification update, the transport specification, and the TypeScript SDK migration guide.

Choose a transport by where the tool needs to run

The decision is not simply “old protocol or new protocol.” Start with the user, environment, and access pattern. The official TypeScript SDK distinguishes local stdio servers from remote Streamable HTTP servers; the two transports solve different deployment problems, rather than representing a universal old-versus-new choice. See the SDK’s server transport documentation.

How should you choose between local stdio and remote Streamable HTTP? Keep stdio when a client must start a process that can directly access the user’s local files, credentials, or development tools. Choose Streamable HTTP when the tool should run once in a managed environment and serve approved clients over a network. A remote server does not have to be exposed to the public internet: you can limit access to the network path and authentication model your organization actually uses.

Do not move a local service just because a newer specification exists. A move adds operational work: a process must stay available, network access must be controlled, credentials need a secure handling plan, and the team needs a way to diagnose failures. If none of those changes solves a real sharing or management problem, keeping the local integration is a valid decision.

Plan the server around shared access, not a protocol headline

A shared MCP service can simplify how you maintain tools, but the service boundary changes what you must operate. Before deploying, account for at least these constraints:

• Local dependencies may not exist on the server. A tool that reads a developer’s local files or relies on an installed command-line tool will not automatically work when moved. Decide whether the data should be copied, mounted, accessed through another service, or kept local.
• Remote access creates an authorization boundary. The fact that a tool uses MCP does not decide who may call it. Set access controls for the server and for the underlying operations; do not treat an unlisted URL or a private network address as a substitute for authorization.
• A long-running process needs an operating plan. You need to know how the service starts, where its configuration lives, how you inspect logs, and what happens after a process or host restart. The specification does not provide this operational layer.
• Multiple containers compete for the same host resources. If the MCP server shares a machine with a database, an AI application, or build jobs, measure the combined workload instead of estimating from the MCP process alone. Do not assume every tool service has the same CPU or memory needs.
• Data ownership does not follow from transport choice. Remote transport does not make your records durable, encrypted, backed up, or private by itself. Those properties depend on the application and the infrastructure you configure.

How do you deploy an MCP server for team use? First decide which tools are genuinely safe and useful to share. Then select a remote transport, define network and authorization controls, deploy the service in an environment the team can maintain, and test it with the real clients that will call it. Keep tools that need a user’s local environment on stdio rather than forcing every integration into the shared server.

A remote setup can remain private to a team. It can run behind an existing access boundary instead of accepting public requests. Keep this article focused on deployment decisions, though: the exact network design depends on your organization’s environment, and MCP transport alone does not supply a complete security or identity policy.

Understand what the July 28, 2026 change makes stateless

The July 28, 2026 protocol release removes the protocol-level initialize / initialized handshake and the Mcp-Session-Id mechanism described for the prior behavior. The official release notes and the dated transport specification are the sources to consult when checking this protocol change.

That change matters for a simple API-style service: the server no longer needs to rely on that protocol-level session mechanism to associate a client with a continuing MCP session. A deployment can therefore make routing decisions without assuming that each request must return to a server process holding that protocol session. This can make multi-instance architecture easier to reason about, but it is not evidence of faster responses or higher capacity. Do not promise a performance improvement based on statelessness alone.

Does a stateless MCP protocol mean you no longer need to save sessions or state? It means the protocol-level session mechanism described in the July 28 revision is no longer required in the same way. It does not mean your application can discard user identity, authorization decisions, database records, job progress, or other business data. If a workflow needs to resume after a restart, the application still needs a durable way to record its progress.

Keep the boundaries clear:

• Protocol state covers the communication behavior defined by the MCP transport and specification.
• Application state covers your users, permissions, records, workflow progress, and tool-specific context.
• Operational state covers deployment configuration, logs, secrets, and any durable data needed to restart or recover the service.

Treating all three as “session state” can lead to a bad migration. Removing a protocol session identifier does not make a write operation idempotent, persist an interrupted job, or restore a database transaction. Put those guarantees in the application and storage layers that own them.

Use this migration sequence before changing clients

Compatibility depends on the client, SDK, server, and protocol revision you actually run. Do not infer support from a product name or from a server being described as “new.” Check the relevant release documentation and the official SDK migration support guide before changing a production connection. The current HTTP server documentation is also a useful reference for the SDK’s remote transport implementation; verify its guidance against the version you plan to deploy.

Use this sequence:

1. Record the current combination. Write down the MCP client, server implementation, SDK release, transport, and protocol version in use. If you cannot identify these, pause the rollout and establish them first.
2. Check each component’s documented support. Confirm whether the client and server support the same protocol behavior. In particular, check whether a client expects the previous initialization handshake or session handling.
3. Separate protocol compatibility from application compatibility. Test tool schemas, authorization, data access, and error handling as well as transport negotiation. A successful connection alone does not prove the tool still behaves correctly.
4. Prepare a test endpoint or non-production environment. Use a representative client and a small set of real operations. Do not use production data unless your organization’s data-handling rules permit it.
5. Test the new connection and failure paths. Verify normal requests, denied access, timeouts, client disconnects, and server restarts. For tools that write data, verify what happens if a client retries after an ambiguous failure.
6. Switch a limited client group first. Keep the previous client configuration available while you check logs and outcomes. Avoid changing every developer’s configuration in one step.
7. Keep a tested rollback path. If the new combination fails because of a handshake, session, or SDK mismatch, restore the prior configuration and investigate the exact component versions before trying again.

Can an older MCP client connect to a newer server? It may, but compatibility is not automatic. Confirm the client’s supported specification revision and the server’s behavior in the versions you intend to use. If older clients still rely on the previous handshake or session behavior, test that exact combination before deployment and keep a fallback until the team confirms that normal operations work.

For a mixed-version team, write down a compatibility matrix before rollout, even if it is only a short internal document. Record the tested client and server versions, transport, expected behavior, and rollback configuration. That gives support staff a concrete diagnosis path when one client works and another does not.

Keep long-running work and write operations in the application layer

An MCP call may start a job, modify a record, or trigger an external action. The protocol’s stateless change does not decide what should happen if the request is repeated, interrupted, or completed while a client is offline. Your tool implementation must define those outcomes.

For operations with durable effects, check that you have:

• A persistent record of the operation. Store enough information to determine whether a job is pending, running, complete, or failed.
• A retry policy that cannot silently duplicate work. Use an idempotency mechanism or another application-level guard where repeating a request could create duplicate effects.
• An explicit recovery path. Decide how an operator can inspect a stuck job and whether it can be safely resumed or must be reconciled manually.
• Useful logs. Record failures and relevant operation identifiers without exposing secrets or unnecessary sensitive content.
• A restart test. Restart the service during a representative operation in a test environment, then check whether the application state is accurate and whether recovery behaves as intended.

Do not assume that a successful transport test covers these cases. Test a tool that reads data and a tool that changes data separately; they have different failure consequences. For a long-running job, check whether the user can see its status after disconnecting and reconnecting, and whether a retry can safely return the existing outcome rather than start a duplicate job.

Assess server fit from the combined workload

A dedicated server makes more sense when several services need to run continuously, the team wants one managed tool endpoint, or the workload shares resources with other self-hosted containers. It is less attractive for a short-lived experiment, a lightweight personal tool, or a service that must scale up and down by the hour. In those cases, local stdio or an existing hosting environment may be simpler.

Do not estimate capacity from the MCP protocol. Measure the actual service, the tools it calls, and the other containers on the host. Pay particular attention to memory use during startup and under representative requests, disk needs for persistent application data, and network requirements for the clients. The right server size follows from that workload; a protocol revision does not define a minimum CPU, memory, request rate, or concurrency level.

If you are comparing hosting options, OVN Cloud’s available server configurations list the actual machine choices. The product information includes AMD EPYC 7543P systems with 32 cores and 64 threads, 128 GB or 256 GB of DDR4-3200 ECC RDIMM memory, and two directly attached 1 TB NVMe drives; confirm the current product page before selecting a configuration. The memory cannot be upgraded in place, so choose the memory tier that matches the combined workload rather than expecting to add capacity later. The drives are not hardware RAID; if you need disk redundancy, plan and test your own software RAID and keep a separate off-host backup.

The available network choices are 250 Mbps, 1 Gbps, or 2 Gbps, each with unmetered traffic, and the listed systems include current Linux options as well as Proxmox VE. Treat these as server options, not MCP requirements. For prices and billing periods, check the current monthly server information; do not estimate a total from generic hosting rates. If you deploy a Linux system, use the SSH access guide for the documented access method.

A dedicated machine is not automatically the best choice. A small shared service may be inexpensive and easier to start, and a local stdio process may be safer and simpler for a tool that only one developer needs. But shared virtual machines can introduce noisy-neighbor contention, CPU allocation may be less predictable, bandwidth and traffic charges can be harder to compare, and the host may limit your control over disk and system choices. If your team needs sustained, exclusive compute for MCP services and other containers, an OVN Cloud AMD bare-metal server is the more appropriate option to evaluate; compare the workload against the listed configuration and operating costs before committing.