Three ways to host
private MCP servers —
remote, proxied, or Hub-installed.

MCP hosting means your MCP servers run on managed infrastructure — Aerostack's edge — instead of on a laptop or a server you maintain. The practical difference for a team is large: every developer and every AI agent connects to the same persistent, always-on endpoint, secrets are stored encrypted and injected at runtime so they never travel through client machines, and access is controlled by workspace roles rather than shared credentials in a Slack thread. Without hosted MCP, teams end up with each person running a local server with their own API key copy, no visibility into what tools are being called, and nothing to audit when something goes wrong. Hosted MCP on Aerostack gives you one authenticated URL your whole team shares, with full observability and the ability to revoke access for any member instantly.

Hosting means your MCP server code runs directly on Aerostack's edge — you upload or connect your implementation and Aerostack executes it globally on Cloudflare Workers with near-zero cold start. Proxying means your existing server stays wherever it already lives (your own infrastructure, a VPC, a third-party provider), and Aerostack puts a secure authenticated gateway in front of it. Your team connects to the Aerostack workspace URL rather than directly to your server, so you gain access control, encrypted secret injection, and per-user analytics without changing your backend at all. Both paths end up in the same place from your team's perspective: one private workspace URL, full RBAC, and secrets that never leave the edge unencrypted.

When you create a workspace on Aerostack, you get a single authenticated URL that represents all the MCP servers, skills, and functions you've composed into it. Every team member — and every AI agent like Claude or Cursor — connects through that one URL using their own authenticated session. Behind it you can have multiple private MCP servers running in parallel; the workspace URL is the aggregated, access-controlled surface. Adding a new server to the workspace makes it available to the entire team immediately, and removing access for a member or revoking a specific server takes effect instantly. No one on the team needs to know the underlying server addresses, rotate credentials, or reconfigure their local MCP client when you change the backend.

Access is governed at the workspace level through role-based permissions. You assign roles to team members — controlling who can call which MCP servers, who can install or remove servers, and who has admin rights over workspace settings. Permissions are enforced at the edge on every request, not just at login time, so revoking a member's access takes effect immediately on their next tool call rather than waiting for a session to expire. Per-user analytics mean you can see exactly which tools each member or agent is invoking, which is useful for debugging and for auditing before you revoke access. This model is fundamentally different from sharing a single API key: each person authenticates individually, and there's no shared secret that can leak and give strangers full access.

Secrets — API keys, tokens, database credentials — are stored encrypted at rest in the workspace and injected into your MCP server at runtime on the edge, using a zero-trust model. The AI model or MCP client your team uses never sees the raw secret values; the server receives them as environment bindings when it executes a tool call. This means a developer can use a tool that calls your internal API without ever having that API's credentials on their machine, and a compromised developer machine can't yield the secret because it was never there. You rotate a secret in the workspace settings and every running server picks up the new value without a redeploy.

Private MCP servers on Aerostack run on Cloudflare Workers at the edge — the same global network used by Aerostack's own infrastructure. There are no servers to provision, no containers to keep warm, and no regions to pick: your server is available globally with near-zero cold start from wherever your team members and AI agents are located. You don't manage capacity, patching, or uptime; the edge runtime handles all of that. Execution is metered against your plan's AI token allowance — the free tier includes 500K tokens per month — and you can bring your own model API key to reduce the platform markup to zero for model calls made through your private servers.

Yes — any MCP-compatible client works. Claude (via the Claude desktop app or API), Cursor, and any other tool that speaks the Model Context Protocol can point to your Aerostack workspace URL and immediately access all the private MCP servers you've composed there. From the client's perspective, it's a single remote MCP endpoint; the fact that it aggregates multiple private servers, enforces RBAC, and injects secrets is invisible to the client. Team members add the workspace URL to their preferred AI tool once and get access to everything their role allows, without managing separate server URLs for each integration.

If you're working alone, the tools you need don't touch private infrastructure, and you're fine with the secrets living in your local environment, a public marketplace MCP installed in your personal workspace is often enough. Aerostack's Explore section has hundreds of pre-built MCP servers for common services — Stripe, GitHub, Notion, and more — and you can install them into your workspace in one click. Private MCP hosting becomes necessary when you have a team sharing the same tools (so access control matters), when the server needs to call internal APIs or private databases that can't be reached from a public server, when you need an audit trail of who called what and when, or when you're building a custom MCP server with proprietary business logic you don't want running on a shared marketplace instance. In short: one person, public tools, no private data — marketplace is fine. Team, internal systems, or custom logic — you want private hosting.