How do I deploy an MCP server built with arcade-mcp to Arcade cloud vs self-hosted?

Most teams adopting MCP hit the same fork in the road: do you run your arcade-mcp server yourself, or let Arcade handle the runtime and wiring via Arcade Cloud? Both paths are valid; the right answer depends on where you need control (network, infra, compliance) vs speed (zero-ops, instant MCP URL, integrated auth).

Quick Answer: You build your MCP server the same way with arcade-mcp; the difference is where you run it. For Arcade Cloud, you plug your tools into an Arcade MCP Gateway and get a hosted MCP URL. For self-hosted, you run the server.py (or equivalent) yourself and point your client/agent directly at it.

---

Frequently Asked Questions

How do I choose between deploying my arcade-mcp server to Arcade Cloud vs self-hosting?

Short Answer: Use Arcade Cloud when you want a managed MCP runtime with hosted auth, MCP Gateway, and no infra to run. Self-host when you need full control over networking, custom environments, or fully air-gapped deployments.

Expanded Explanation:
With arcade-mcp, building the MCP server is the same regardless of where you run it. The real choice is operational: Arcade Cloud gives you the “runtime between AI and action” as a managed service—hosted MCP Gateway, OAuth integration, tenant isolation, logs, and direct compatibility with tools like Cursor, Claude, and LangGraph via a single MCP URL.

Self-hosted deployment is better when you have hard constraints: private VPC only, on-prem or air-gapped clusters, custom hardware, or specific security policies that require MCP to stay inside your network boundary. You still get the same tool schemas and runtime semantics; you’re just responsible for running and securing the process.

Key Takeaways:

• Cloud: fastest path from arcade-mcp server to live MCP URL with no infra work.
• Self-host: maximum control over network, hardware, and compliance boundaries.

---

What is the process to deploy an arcade-mcp server with Arcade Cloud?

Short Answer: Build your MCP server with arcade-mcp, then expose those tools through an Arcade MCP Gateway, which gives you a hosted MCP URL your agents can call.

Expanded Explanation:
Arcade Cloud wraps your MCP server in a managed runtime. You sign up, create an MCP Gateway, pick which tools to expose (e.g., Gmail, Google Calendar, Slack, GitHub), and wire in auth. The result: a single URL like https://api.arcade.dev/mcp/my-agent that any MCP-compatible agent can use. Credentials never touch the model; they’re stored and injected at runtime by the Arcade platform.

Under the hood, Arcade Cloud handles what most teams don’t want to own: token storage/refresh, permission mapping (user-specific access, not service accounts), and secure tool execution. You focus on tool schemas and behavior; Arcade handles the “it works at 3 a.m.” part.

Steps:

1. Build your MCP server locally

   • Install the CLI:

     uv tool pip install arcade-mcp
     

   • Create a new MCP server project:

     arcade new my_server
     cd my_server
     uv run server.py
     

   • Implement your tools, e.g., Google.SendEmail, Gmail.ListEmails, etc.

2. Create an Arcade Cloud account and MCP Gateway

   • Create a free Arcade account to get access to MCP Gateway.
   • In the Arcade dashboard, go to MCP Gateway → Create MCP Gateway.
   • Choose a slug (for example, my-agent), which becomes your MCP URL:

     https://api.arcade.dev/mcp/my-agent
     

3. Select tools and connect your agent

   • In MCP Gateway, select the specific tools (from Arcade’s managed tools and/or your own MCP server) that should be exposed.
   • Configure your IDE/agent builder (Cursor, Claude, LangGraph, etc.) with the MCP URL from Arcade Cloud.
   • Use Arcade’s SDK patterns (client.auth.start(...), wait_for_completion) to kick off just-in-time OAuth and run tools with user-specific permissions.

---

What’s the difference between deploying to Arcade Cloud and running arcade-mcp self-hosted?

Short Answer: Arcade Cloud is a managed MCP runtime and gateway; self-hosted means you run the arcade-mcp server process and surrounding auth/runtime stack yourself.

Expanded Explanation:
Functionally, both options expose MCP tools that agents can call. The differences show up in who owns the runtime and guardrails.

With Arcade Cloud:

• Arcade provides hosted MCP Gateway and runtime.
• You get centralized configuration, OAuth integration, credentials vaulting, audit logs, RBAC/SSO, and tenant isolation.
• You typically integrate via a single MCP URL and rely on Arcade for token exchange and refresh logic.

With self-hosting:

• You run server.py (or equivalent) wherever you want—cloud, VPC, on-prem, or air-gapped.
• You must wire your own auth flows (OAuth/IDP), secret storage, logging, scaling, and observability.
• You can still plug into Arcade’s ecosystem (e.g., local dev with arcade configure), but you’re the runtime operator.

Comparison Snapshot:

• Option A: Arcade Cloud

  • Managed MCP Gateway + runtime.
  • Hosted OAuth, user-specific auth model, zero token exposure to LLMs.
  • Best when you want “from chat to action” in minutes, without building your own auth and execution layer.

• Option B: Self-hosted arcade-mcp

  • You run uv run server.py (or container, systemd service, etc.).
  • You own networking, scaling, logs, and integration with your internal identity stack.
  • Best when you need tight infra control (VPC, on-prem, air-gapped).

• Best for:

  • Use Arcade Cloud for most internet-connected, multi-user production agents.
  • Use self-hosted when security policy or latency requires MCP to live entirely in your environment.

---

How do I actually run an arcade-mcp server in a self-hosted environment?

Short Answer: Run the arcade-mcp server as a long-lived process (or container) in your own infrastructure, then point your MCP clients at its endpoint.

Expanded Explanation:
Self-hosting is straightforward because arcade-mcp is just Python code. You use the same arcade new my_server flow, but instead of letting Arcade host it, you deploy the resulting server script or container into your infrastructure.

From there, you decide how to expose it: internal-only, via a load balancer, behind mTLS, or inside an air-gapped cluster. You’re responsible for health checks, restarts, and scaling. If you want evals or local tooling, you can run everything locally: “fully local and offline-friendly,” with Evals and tools running where your credentials live (BYOC – bring your own credentials).

What You Need:

• Infrastructure to run the process:
  • A VM, Kubernetes cluster, or bare-metal host.
  • A process manager (systemd, supervisord) or orchestration (K8s, Nomad) to keep the server up.
• Access + security controls:
  • Network routing (DNS/LB) to expose the MCP endpoint to clients.
  • Your own auth/identity story (OAuth, SSO/SAML, RBAC) and secret storage, or an internal gateway that sits in front of the server.

---

How should I think strategically about Arcade Cloud vs self-hosting for production agents?

Short Answer: Use Arcade Cloud as your default for multi-user production agents and only self-host when infra or compliance requires it.

Expanded Explanation:
Most agent projects don’t fail because the model can’t reason; they fail because the agent can’t safely authenticate and execute actions in real systems. Rebuilding OAuth, token storage/refresh, and permissioning for every integration—then hardening that for production—is expensive and brittle.

Arcade Cloud exists to offload that: you get Secure Agent Authorization (agents act with user-specific permissions, not service accounts), zero token exposure to LLMs, audit trails, and scoped MCP tools designed for reliability and cost control. That’s a better default than rolling your own runtime unless you absolutely must.

Self-hosting still makes sense for certain environments—especially if you’re mandated to keep all execution in a VPC, on-prem, or air-gapped setup. In those cases, you can still follow Arcade’s patterns (clear tool boundaries, permission gates, evals), but you accept the operational and security overhead of owning the runtime.

Why It Matters:

• Speed to value: Arcade Cloud lets you go from “agent in a notebook” to “agent safely sending Gmail, creating Calendar events, posting to Slack, and updating Salesforce” in days, not months of auth and infra work.
• Risk reduction: Centralized authorization, RBAC/SSO/SAML, audit logs, tenant isolation, and scoped MCP tools reduce the chance your agent becomes “a Ferrari that can only drive in your driveway” or worse, a security exception your team can’t explain.

---

Quick Recap

With arcade-mcp, you build the same MCP server regardless of where it runs. Arcade Cloud turns that into a managed MCP runtime with an MCP Gateway URL, hosted OAuth, user-specific authorization, and enterprise controls. Self-hosting your arcade-mcp server gives you full control over where and how it runs—ideal for VPC, on-prem, or air-gapped constraints—but requires you to own auth, scaling, logs, and governance. For most production agents, Arcade Cloud is the fastest and safest path from “chat” to real actions across Gmail, Calendar, Slack, GitHub, HubSpot, Salesforce, and more.

Next Step

Get Started