Why host your own MCP server
The Model Context Protocol defines a standardised communication layer between an AI agent and its data sources or tools. An MCP server exposes resources (files, databases, APIs) and tools (executable functions) that any compatible client can consume — whether that is Claude Desktop, an IDE like Cursor, or a platform like Open WebUI. The specification published on 28 July 2026 introduces two structural changes. The first is a shift to stateless mode: each request is now self-contained, which simplifies deployment behind a load balancer or reverse proxy. The second is the emergence of MCP Apps — packaged, ready-to-deploy servers that you launch the way you would launch a container. Self-hosting an MCP server gives you full control over the data being processed — it never leaves your infrastructure — and lets you connect internal tools without exposing your secrets to a third-party service. It is also a way to iterate quickly on your own tools without waiting for a publication in a public registry.
What you gain by self-hosting
- Data sovereignty — your contexts, API keys and documents never transit through an external service.
- Universal compatibility — an MCP server that complies with the spec can be consumed by any conforming client, with no vendor lock-in.
- Controlled latency — a server hosted in your region responds in a few milliseconds; a public relay can introduce unnecessary round trips.
- Full customisation — you add, modify or remove tools without depending on an external release cycle.
- Predictable cost — a VPS starting at 99 DH/month/month is enough for a basic MCP server, with no per-request billing.
Prerequisites before you start
A basic MCP server is remarkably lightweight. A VPS with 1 vCPU and 1 GB of RAM is sufficient for development workloads and small teams. If you plan to serve tools to multiple simultaneous agents or run local embeddings, aim for 2 GB instead.
On the software side, you have two runtime options: Docker, which isolates the server in a container and makes updates straightforward, or Node.js (version 20 or higher) for a direct installation. MCP servers written in Python run via uvx or a virtual environment. In all cases, the npm or pip package manager must be available.
Networking: port 443 must be open and a valid TLS certificate is required. The MCP 2026-07-28 spec requires HTTPS for HTTP Streamable transports; an unencrypted connection will be rejected by most modern clients. A domain name pointing to your VPS is therefore necessary — we will use your-domain.com in the examples below.
Deploy an MCP server in 5 steps
Choose and clone a reference MCP server
The official modelcontextprotocol/servers registry on GitHub lists dozens of reference servers: filesystem, fetch, PostgreSQL, GitHub, Brave Search, and more. Choose the one that fits your use case. On your VPS, clone the repository: git clone https://github.com/modelcontextprotocol/servers.git, then navigate to the subfolder of your chosen server, for example cd servers/src/fetch.
Build and start the Docker container
If a Dockerfile is present, build the image: docker build -t my-mcp-server .. Then start the container, exposing the server's HTTP port — usually 3000 or 8080 depending on the implementation: docker run -d --name mcp-server -p 127.0.0.1:3000:3000 my-mcp-server. Binding to 127.0.0.1 ensures the port is not directly exposed to the internet — nginx will handle TLS termination.
Configure the nginx reverse proxy with TLS
Install nginx and obtain a certificate via certbot --nginx -d your-domain.com. In the server block for port 443, add a location / that proxies to http://127.0.0.1:3000. Reload nginx with systemctl reload nginx. Your MCP server is now accessible at https://your-domain.com/ over HTTPS.
Enable OAuth 2.0 authentication
The MCP 2026-07-28 spec defines an authorisation profile based on OAuth 2.0 with PKCE. For team use, configure an identity provider (self-hosted Keycloak, or a service like GitHub OAuth Apps) and register your server as a protected resource. For personal or development use, a static token in an Authorization: Bearer <token> header is sufficient initially, provided HTTPS is active. Never deploy an MCP server without authentication on a public port.
Test, then connect to Open WebUI or Dify
From your local machine, configure Claude Desktop by adding your server to claude_desktop_config.json: in the mcpServers section, declare an http type server pointing to https://your-domain.com. Verify that your tools appear in the interface palette. To go further, connect the same server to Open WebUI or Dify: these platforms accept an MCP HTTP endpoint in their model settings, allowing you to reuse the exact same server without any modification.
Always enable nginx access logs for your MCP server and set up an alert on 401 and 403 status codes. An MCP server exposed without authentication or with a compromised token can become a data exfiltration vector if your tools access sensitive resources. Also consider restricting allowed origins via the Access-Control-Allow-Origin header if your server is consumed from a browser.
Towards a complete AI environment on your VPS
An MCP server on its own is just one component. Its value emerges when it integrates into an ecosystem: a conversational interface like Open WebUI to expose your tools to your users, or an orchestration platform like Dify to compose multi-step workflows from several MCP servers. ServOrbit offers VPS plans optimised for these workloads, with snapshots for backups and a dedicated IPv4 address. If you want to go further, our guides on hosting Open WebUI and deploying Dify on a VPS describe how to combine these building blocks. The resulting architecture — MCP server + orchestrator + interface — fits comfortably on one or two VPS instances and gives you a sovereign AI environment, with no default dependency on cloud APIs.
