---
title: "Obot Alternative — Zuplo"
description: "Obot alternative: a programmable MCP gateway built on your existing OpenAPI and policy pipeline. OAuth 2.1, per-user brokering, managed or self-hosted. SOC 2."
canonicalUrl: "https://zuplo.com/api-gateways/obot-alternative-zuplo"
pageType: "comparison"
competitor: "Obot"
subtitle: "An MCP Gateway Alternative to Obot's Open-Source Kubernetes-Native MCP Platform"
---

# Zuplo vs Obot

_An MCP Gateway Alternative to Obot's Open-Source Kubernetes-Native MCP Platform_

> Obot alternative: a programmable MCP gateway built on your existing OpenAPI and policy pipeline. OAuth 2.1, per-user brokering, managed or self-hosted. SOC 2.

## Why Teams Move Away from Obot

### Kubernetes-Native Self-Host in Production

Obot's production deployment is self-hosted on Kubernetes with an external Postgres database, S3-compatible object storage, and a cloud KMS (AWS KMS or Google Cloud KMS) for encryption at rest. A Helm chart is provided. Teams without an existing Kubernetes practice carry the operational cost of running this stack themselves. Obot now offers a managed hosted option, Obot Cloud, with a free two-week trial of a dedicated gateway environment, but specific SLA, pricing, and regional data-residency terms are not publicly documented.

### Bundled Platform, Not a Focused Gateway

Obot is positioned as a complete MCP platform with four components: MCP Gateway, MCP Hosting, MCP Registry, and the Obot Agent chat client (replacing the deprecated Obot Chat), plus an MCP Server Shim sidecar. Recent releases grew the bundle further: skills distribution and device management for local AI clients, and an LLM Gateway that proxies OpenAI- and Anthropic-compatible model traffic for external coding agents. Teams that want a thin MCP gateway sitting in front of existing APIs and SaaS MCP servers, without adopting an agent runtime, a server hosting layer, a model proxy, and an end-user chat surface, may not need most of the bundle.

### Compliance Posture Is BYO

Obot has not publicly published its own SOC 2 Type II, HIPAA, ISO 27001, or FedRAMP attestations. The stated posture is that data stays in the customer's environment when self-hosted, so the customer owns the broader compliance program and evidence collection. SLA and 24/7 support terms for Obot Enterprise Edition are not publicly listed.

### No Native OpenAPI-to-MCP Ingestion

Obot's model is bring-your-own MCP server: tool servers run in Docker or as Kubernetes Deployments in a dedicated namespace and connect into the gateway. A native OpenAPI-to-MCP generator is not surfaced in public Obot docs. Teams with existing REST APIs typically author MCP servers separately, or wrap their APIs in a container before exposing them through Obot.

## About Obot

Obot is the flagship open-source product of Obot AI, the company that formally rebranded from Acorn Labs on September 23, 2025, the same day it announced a $35M seed co-led by Mayfield Fund and Nexus Venture Partners. Leadership includes CEO Sheng Liang (ex-Rancher Labs CEO and SUSE President of Engineering & Innovation post-acquisition), president Shannon Williams, and Chief Architect Darren Shepherd (creator of k3s). Public databases list the company in Cupertino, California, and Obot AI is a Silver member of the Linux Foundation's Agentic AI Foundation (AAIF), announced December 2025, having donated the MCP Dev Summit and podcast to the foundation. Obot calls itself an "open-source MCP Gateway and AI Platform" and a "complete MCP Platform: Hosting, Registry, Gateway, and Chat Client." Its architecture has four headline components — MCP Gateway as the data plane, MCP Hosting that runs MCP servers in Docker or Kubernetes, an MCP Registry catalog, and the Obot Agent client — plus a protocol-aware MCP Server Shim sidecar that runs alongside every MCP server (including remote ones) to handle authorization, audit logging, webhook filters, and OAuth 2.0 Token Exchange (RFC 8693), and a newer LLM Gateway that acts as an OpenAI- and Anthropic-compatible model endpoint for external clients such as Claude Code. All upstream servers are re-exposed to clients via streamable HTTP from the gateway, regardless of their underlying transport. The core obot repository is MIT licensed and self-hostable from source. Adjacent repositories (`nanobot`, `mcp-oauth-proxy`, and the now-archived `tools`) ship under Apache 2.0; the `mcp-catalog` repository does not publish a LICENSE file. An Obot Enterprise Edition — unlocked by a license key — adds Okta, Microsoft Entra, Auth0, and JumpCloud IdP support and enterprise model providers (Azure OpenAI, Amazon Bedrock) along with commercial support, with pricing on request. Obot also markets a managed hosted offering, Obot Cloud, with a free two-week trial of a dedicated, fully hosted gateway environment alongside the self-hosted open-source build. Obot publishes 70+ pre-built enterprise integrations across Microsoft, Google, Salesforce, Atlassian, AWS, and more, plus a community catalog at github.com/obot-platform/mcp-catalog. For teams that want a fully managed MCP gateway extending an API platform they already operate, with a spec-conformant OAuth 2.1 authorization server, OpenAPI-to-MCP ingestion, and predictable per-request pricing, Zuplo is the focused alternative.

## Why Choose Zuplo

Zuplo is a programmable API gateway and management platform whose MCP Gateway extends the same OpenAPI and policy pipeline you already use for REST traffic. The MCP Gateway targets the MCP authorization spec revision 2025-11-25 over streamable HTTP and bundles a complete OAuth 2.1 authorization server by default with Dynamic Client Registration (RFC 7591), PKCE S256, authorization server metadata at `.well-known/oauth-authorization-server` (RFC 8414), protected resource metadata at `.well-known/oauth-protected-resource` (RFC 9728), and tokens bound to a virtual MCP server via resource indicators (RFC 8707). Teams pick per-user or shared-OAuth upstream credential modes, federate any remote MCP server (Linear, Stripe, Notion, GitHub, and any MCP server reachable over streamable HTTP) behind one gateway URL, compose virtual MCP servers with per-tool allow-lists, and ship the whole thing on managed edge across 300+ data centers, managed dedicated on AWS, Azure, GCP, Akamai, or Equinix, or self-hosted Kubernetes. SOC 2 Type II controls, audit logs, and predictable per-request pricing apply across all deployment modes.

## Feature Comparison

### Product Category

_Focused MCP Gateway extending an API platform vs. bundled Kubernetes-native MCP platform with hosting, registry, and agent_

- **Zuplo** — Programmable API gateway and management platform that handles REST and GraphQL traffic and exposes a dedicated MCP Gateway on the same runtime, policy pipeline, and OpenAPI workflow.
- **Obot** — Open-source MCP platform bundling four headline components — MCP Hosting (runs MCP servers in Docker or Kubernetes), MCP Registry, MCP Gateway, and the Obot Agent client — plus a protocol-aware MCP Server Shim sidecar that runs alongside every MCP server and a newer LLM Gateway that proxies OpenAI- and Anthropic-compatible model traffic for external clients.

### MCP Spec Compliance

_MCP authorization spec 2025-11-25 over streamable HTTP vs. MCP-standards compliance over streamable HTTP without a publicly pinned spec date_

- **Zuplo** — Targets the MCP authorization spec revision 2025-11-25 over streamable HTTP, with the gateway requiring the `MCP-Protocol-Version: 2025-11-25` header. Tested with Claude Desktop, Claude Code, Cursor, ChatGPT (including the OpenAI Apps SDK), VS Code, and MCP Inspector.
- **Obot** — Describes itself as MCP-standards-compliant. All upstream servers are re-exposed via streamable HTTP from the gateway regardless of their underlying transport. Tested clients include Claude Desktop, Cursor, VS Code, ChatGPT, GitHub Copilot, and Cline, plus workflow frameworks n8n and LangGraph. Obot has not publicly pinned a specific MCP spec revision.

### OAuth 2.1 Authorization Server

_Documented OAuth 2.1 AS RFC stack (7591/8414/9728/8707) plus 11 first-class IdP presets vs. OAuth 2.1 with DCR + token-exchange shim and a standalone OAuth proxy_

- **Zuplo** — Complete OAuth 2.1 authorization server bundled by default. Dynamic Client Registration per RFC 7591 (accepted at `/oauth/register`), PKCE S256 required as the MCP spec mandates, authorization server metadata at `.well-known/oauth-authorization-server` (RFC 8414), protected resource metadata at `.well-known/oauth-protected-resource/{routePath*}` (RFC 9728), and tokens bound to a route's `operationId` via resource indicators (RFC 8707). First-class IdP presets ship for Auth0, Cognito, Clerk, Google, Keycloak, Logto, Entra, Okta, OneLogin, PingOne, and WorkOS, plus a generic OIDC fallback.
- **Obot** — OAuth 2.1 with PKCE. A standalone `mcp-oauth-proxy` ships under Apache 2.0 as a full OAuth 2.1 authorization server. Obot builds a Dynamic Client Registration shim (RFC 7591) in front of providers that do not support DCR natively, notably Microsoft Entra, and the MCP Server Shim handles OAuth 2.0 Token Exchange (RFC 8693). Explicit conformance to RFC 8414, RFC 9728, or RFC 8707 is not publicly documented.

### Credential Models for Upstream MCP Servers

_Per-user and shared-OAuth modes plus upstream API key policies on the same route vs. shared-client OAuth + self-auth servers + M2M API keys_

- **Zuplo** — Two OAuth modes ship today via the `mcp-token-exchange-inbound` policy — per-user OAuth and shared-OAuth (admin configures one upstream client, users still authenticate individually). Upstream API keys are configured with separate policies (`set-upstream-api-key-inbound`, `set-headers-inbound`) and combine with the OAuth modes on the same route, all in JSON config.
- **Obot** — Supports per-user OAuth, a shared OAuth grant model where the admin configures a single client ID and secret but users still each run the OAuth flow, and self-authenticating servers where the MCP server handles its own multi-tenancy. API keys for machine-to-machine callers are supported. A per-user or shared vault-stored upstream API key model is not surfaced as a primary path; Obot's story is OAuth-centric.

### Virtual MCP Servers / Federation

_Capability allow-lists configured in JSON over any upstream MCP server vs. composite servers in the admin UI with name/description overrides_

- **Zuplo** — Bind any route to an upstream MCP server and compose virtual MCP servers using the `mcp-capability-filter-inbound` policy, which applies exact allow-lists over upstream tools, prompts, and resources — without forking the upstream. Routes and policies are configured in JSON (`routes.oas.json`, `policies.json`) and deployed via GitOps.
- **Obot** — Composite servers combine one or more single-user, multi-user, and remote MCP servers into a single virtual MCP server. Administrators select exactly which tools from each server to expose, override tool names and descriptions, and apply per-group access policies. Obot's Git-backed catalog workflow covers standard and multi-user server templates but does not support the composite runtime, so composite servers are managed through the admin UI.

### Pre-Built Upstream MCP Catalog

_Federates any streamable HTTP MCP server with worked examples vs. 70+ pre-packaged enterprise SaaS integrations and a community catalog_

- **Zuplo** — Federates any MCP server reachable over streamable HTTP. Documented worked examples cover Linear, Stripe, and Notion, with broader use cases cited across Linear, Notion, Stripe, GitHub, Slack, and internal services.
- **Obot** — Publishes 70+ pre-built enterprise integrations across Microsoft, Google, Salesforce, Atlassian, AWS, and more, along with a community catalog repo at `obot-platform/mcp-catalog`.

### API to MCP Ingestion

_OpenAPI-to-MCP via the bundled MCP Server handler vs. bring-your-own MCP server in Docker or Kubernetes_

- **Zuplo** — Zuplo's separate MCP Server handler turns OpenAPI operations into MCP tools natively in the same project as the MCP Gateway, so existing REST APIs become MCP servers without authoring separate tool code. The MCP Server handler and the MCP Gateway can coexist in one Zuplo project.
- **Obot** — Bring-your-own MCP server via Docker or Kubernetes. Tool servers can be Node.js, Python, or container-based, and filter webhooks can be written as MCP servers. A native OpenAPI-to-MCP generator is not surfaced in public Obot docs.

### Deployment Models

_Managed global edge + managed dedicated across clouds + self-hosted Kubernetes vs. self-host on Kubernetes with Postgres, S3, KMS, plus a managed Obot Cloud option (SLA/pricing undocumented)_

- **Zuplo** — Managed edge across 300+ data centers (default), managed dedicated single-tenant on AWS, Azure, GCP, Akamai, or Equinix, and self-hosted Kubernetes when full data residency is required.
- **Obot** — Self-hosted on Docker for development or Kubernetes for production, with an external PostgreSQL 17+ database (with pgvector), S3-compatible object storage (or Azure Blob) for legacy chat workspace and workflow artifacts, and a cloud KMS (AWS KMS, Azure Key Vault, or Google Cloud KMS) for encryption at rest. A Helm chart is available at `charts.obot.ai`. Obot also offers a managed hosted option, Obot Cloud, with a free two-week trial of a dedicated gateway environment, but specific single-tenant SLA, pricing, and regional data-residency terms are not publicly documented.

### Licensing and Open Source

_Commercial gateway with optional self-host on Enterprise vs. MIT-licensed OSS core with Apache 2.0 adjacents and LF AAIF membership_

- **Zuplo** — Commercial platform. Self-hosted Kubernetes deployment is available on Enterprise plans.
- **Obot** — Core `obot` repository is MIT licensed. Adjacent repositories (`nanobot`, `mcp-oauth-proxy`, and the now-archived `tools`) ship under Apache 2.0; the `mcp-catalog` repository does not publish a LICENSE file. Obot AI is a Linux Foundation AAIF Silver member and donated the MCP Dev Summit to the foundation.

### Enterprise Identity (SSO + RBAC)

_Enterprise SSO via Auth0 + account/project/environment-scoped RBAC vs. OIDC SSO with predefined roles and enterprise IdPs gated to the paid edition_

- **Zuplo** — Enterprise SSO via Auth0 supports common identity providers including Azure AD, Okta, and Google Workspace. Account- and project-scoped roles (Admin, Developer, Member) with environment-scoped permissions (Production, Preview, Development) are included on Enterprise.
- **Obot** — SSO via OIDC and OAuth: GitHub and Google ship in the open-source build; Okta, Microsoft Entra, Auth0, and JumpCloud are gated behind Obot Enterprise Edition. RBAC ships with predefined roles (Owner, Admin, Power User+, Power User, Basic User, Auditor) that extend to per-MCP-server and per-composite-server policies. SAML and SCIM support are not surfaced in public docs.

### Compliance and Audit Readiness

_SOC 2 Type II + pen test reports under NDA + GDPR rights vs. self-hosted data sovereignty with customer-owned compliance program_

- **Zuplo** — SOC 2 Type II accredited, third-party penetration test reports available under NDA, audit logs across the control plane, and GDPR rights honored in the privacy policy. Trust report at trust.zuplo.com.
- **Obot** — Obot has not publicly published its own SOC 2 Type II, HIPAA, ISO 27001, or FedRAMP attestations. The stated posture is that data stays in the customer's environment when self-hosted, so the customer owns the compliance program and evidence collection. Comprehensive audit logging is provided through the MCP Server Shim.

### Observability

_Typed events + 8 native log destinations + OTLP/Honeycomb + documented reason codes vs. shim logs + native admin dashboard + filter webhooks + OTel tracing_

- **Zuplo** — Typed analytics events across three families (`mcp_request`, `capability_invocation`, `auth_event`), trace-ready structured logs with tenant, MCP session, capability, latency, and failure origin, log destinations including AWS CloudWatch, Datadog, Dynatrace, Google Cloud Logging, Loki, New Relic, Splunk, and Sumo Logic plus OTLP exporters to Honeycomb and other OpenTelemetry-compatible backends, and standardized reason codes (`missing_token`, `invalid_audience`, `connect_required`, `upstream_timeout`, and more) on every failure.
- **Obot** — The MCP Server Shim logs every gateway request including filter decisions. A native admin dashboard provides CPU and memory capacity monitoring across MCP servers. Filter webhooks enforce PII redaction and content policy. OpenTelemetry HTTP-request tracing instrumentation is included; dedicated Datadog and Honeycomb exporter integrations are not surfaced in public docs.

## FAQ

**What is Obot and how does it compare to Zuplo's MCP Gateway?**

Obot is an open-source MCP platform from Obot AI (formerly Acorn Labs) that bundles an MCP Gateway, MCP server hosting, an MCP registry, and the Obot Agent client into one Kubernetes-native deployment. Zuplo's MCP Gateway is a focused MCP gateway built into a programmable API management platform, with a complete OAuth 2.1 authorization server, an adjacent MCP Server handler that turns OpenAPI operations into MCP tools, and managed edge, managed dedicated, and self-hosted Kubernetes deployment options. Both products federate upstream MCP servers, broker credentials, and let admins compose virtual MCP servers with per-tool selection.

**Is Obot an API gateway?**

No. Obot positions itself as an MCP gateway and AI platform, not as a general-purpose API gateway. Its job is to govern MCP servers, proxy LLM model traffic through its LLM Gateway, and power MCP-enabled agents — not to handle arbitrary REST or GraphQL traffic, transformations, rate limiting on non-MCP routes, or developer portal monetization. Teams running a REST or GraphQL API that also need an MCP surface typically pair Obot with a separate gateway, or consolidate the gateway and MCP surface on a platform like Zuplo.

**How do the OAuth authorization stories compare?**

Zuplo's MCP Gateway bundles a complete OAuth 2.1 authorization server by default, with Dynamic Client Registration per RFC 7591 (accepted at `/oauth/register`), PKCE S256, authorization server metadata at `.well-known/oauth-authorization-server` (RFC 8414), protected resource metadata at `.well-known/oauth-protected-resource/{routePath*}` (RFC 9728), and tokens bound to a route's `operationId` via resource indicators (RFC 8707). Obot supports OAuth 2.1 with PKCE, builds a DCR shim (RFC 7591) in front of providers that do not support DCR natively (notably Microsoft Entra), and handles OAuth 2.0 Token Exchange (RFC 8693) in the MCP Server Shim. A standalone `mcp-oauth-proxy` is available under Apache 2.0. Explicit Obot conformance to RFC 8414, RFC 9728, and RFC 8707 is not documented publicly.

**Can I migrate my existing REST API to MCP with Obot?**

Obot's model is bring-your-own MCP server: tool servers run in Docker or as Kubernetes Deployments and connect into the gateway. A documented OpenAPI-to-MCP generator is not surfaced in public Obot docs, so teams typically author MCP servers separately or wrap their APIs in a container before exposing them through Obot. By contrast, Zuplo's MCP Server handler exposes OpenAPI operations as MCP tools natively, and can run alongside the MCP Gateway in the same Zuplo project.

**How does the deployment story compare?**

Zuplo offers three deployment modes from a single platform: managed edge across 300+ data centers (default), managed dedicated single-tenant on AWS, Azure, GCP, Akamai, or Equinix, and self-hosted Kubernetes when full data residency is required. Obot's production deployment is self-hosted on Kubernetes with an external PostgreSQL 17+ database, S3-compatible object storage, and a cloud KMS (AWS KMS, Azure Key Vault, or Google Cloud KMS), installed via a Helm chart at `charts.obot.ai`. Obot also offers a managed hosted option, Obot Cloud, with a free two-week trial of a dedicated gateway environment, but specific single-tenant SLA, pricing, and regional data-residency terms are not publicly documented.

**How do compliance and certifications compare?**

Zuplo is SOC 2 Type II accredited with reports available under NDA, performs penetration testing regularly with third-party reports available under NDA, and honors GDPR rights in its privacy policy (full status at trust.zuplo.com). Obot has not publicly published its own SOC 2 Type II, HIPAA, ISO 27001, or FedRAMP attestations; the stated posture is that data stays in the customer's environment when self-hosted, so the customer owns the compliance program and evidence collection. SLA and 24/7 support terms for Obot Enterprise Edition are not publicly listed.

**Where does Obot genuinely win over Zuplo?**

Obot is the right pick for teams that want a fully open-source MCP platform under MIT (with Apache 2.0 adjacents), bundled with MCP server hosting, a registry, and an agent and chat client, all self-hosted in their own Kubernetes cluster. Founder pedigree (ex- Rancher Labs CEO and the creator of k3s), Linux Foundation AAIF Silver membership, and a Microsoft Entra DCR shim are real strengths. Kubernetes-native platform teams that treat k8s ops as a feature, not a tax, will be comfortable operating Postgres, S3-compatible storage, and a cloud KMS themselves.

**Can I use Zuplo alongside Obot?**

Yes. Some teams run Obot inside their cluster as an MCP hosting surface for internal MCP servers, while running Zuplo in front of their public APIs and external MCP traffic. With Zuplo, the MCP gateway, AI gateway, and API gateway are consolidated in one platform, which most teams prefer for operational simplicity, but a mixed deployment is possible if you already depend on Obot's hosting and agent surfaces.