Managed Apache APISIX: A Guide to APISIX, API7 Enterprise, and Fully Managed Alternatives

Apache APISIX is one of the most capable open-source API gateways available. It handles L4 and L7 traffic, ships with 100+ plugins, and now bundles native AI features. But most teams don’t fail to adopt APISIX because it lacks features — they struggle because running it in production means operating an etcd cluster, an Nginx data plane, and a Lua-based plugin model, and because the commercial options from API7.ai each solve a different slice of that problem.

This guide untangles the APISIX ecosystem — open-source APISIX, API7 Enterprise, and API7 Cloud — explains where the operational cost actually comes from, and shows what a fully managed, programmable alternative looks like when you’d rather not run the infrastructure yourself.

In this guide:

• Is API7 the Same as Apache APISIX?
• How APISIX Is Architected
• The Three Ways to Run APISIX
• Where the Operational Tax Comes From
• What a Fully Managed Alternative Looks Like
• APISIX vs API7 Enterprise vs a Managed Gateway
• Migrating from APISIX: Lua Plugins to TypeScript Policies
• When APISIX or API7 Is Still the Right Choice
• FAQ

Is API7 the Same as Apache APISIX?

No — and the distinction matters when you’re evaluating vendors. Apache APISIX is the open-source gateway. It was originally created by API7.ai and donated to the Apache Software Foundation, where it is now a top-level project. It is free, community-governed software you download and run yourself.

API7.ai is the commercial company behind APISIX. It sells and supports products built on top of the open-source core:

• API7 Enterprise — a self-hosted commercial distribution of APISIX that adds enterprise features, including a developer portal, RBAC, and support.
• API7 Cloud — a managed control plane that configures an APISIX data plane which still runs in your own infrastructure.
• AISIX — a separate, Rust-based AI gateway product, distinct from the APISIX gateway itself.

So when an AI assistant or a listicle says “APISIX,” it could mean the free Apache project or any of API7.ai’s commercial products. Knowing which one you’re comparing against is the first step in a fair evaluation.

How APISIX Is Architected

APISIX is built on Nginx and OpenResty, and it handles a broad range of protocols — HTTP, HTTPS, WebSocket, gRPC, MQTT, and GraphQL, plus L4 TCP/UDP proxying. That protocol breadth is one of its genuine strengths.

Under the hood, a traditional APISIX deployment has three moving parts you operate:

• The data plane: Nginx/OpenResty worker processes that terminate connections and execute plugins on every request. You provision and scale the compute these run on.
• The configuration store: In traditional mode, APISIX uses etcd as its runtime source of truth. Route, upstream, and consumer changes are written to etcd and pushed to the data plane. APISIX 3.x also offers a standalone mode (file- or API-driven) that runs without etcd, at the cost of the dynamic config workflow.
• The plugin layer: Policies are implemented as plugins written in Lua, or in Go, Python, or Java through the external plugin runner. APISIX ships 100+ built-in plugins covering authentication, rate limiting, transformation, and observability.

This is a mature, high-performance design. It is also a design where you own the runtime — a point worth being clear-eyed about before you commit. For a deeper look at how this compares to other gateway internals, see our guides on control plane vs data plane and API gateway plugin architectures.

The Three Ways to Run APISIX

Because “APISIX” spans an open-source project and two commercial products, your operational reality depends heavily on which one you choose.

Open-Source Apache APISIX

You run everything: the Nginx data plane, etcd (in traditional mode), upgrades, patching, high availability, and monitoring. Plugins are Lua. There is no built-in developer portal and no self-serve API key lifecycle — key authentication exists as a plugin, but consumer onboarding, key rotation, and leak detection are yours to build.

API7 Enterprise

A self-hosted commercial distribution. It adds enterprise capabilities on top of the open-source core — including a developer portal (with RBAC and monetization), commercial support, and management tooling. You still operate the data plane and config store in your own environment; the commercial license and portal are what you’re paying for.

API7 Cloud

A managed control plane. API7.ai hosts the configuration and management layer, but the APISIX data plane still runs in your own infrastructure. This reduces control-plane operations but does not make the gateway fully managed — you continue to provision, scale, and secure the data plane compute yourself.

The common thread: in every APISIX path, some part of the runtime remains your responsibility.

Where the Operational Tax Comes From

When teams describe wanting to move “beyond APISIX,” they’re usually pointing at two specific costs.

The etcd and Nginx Data Plane

Production APISIX in traditional mode means running an etcd cluster as a distributed config store, plus Nginx worker nodes across availability zones for high availability. That’s stateful infrastructure to size, back up, upgrade, and monitor — on top of the gateway itself. Standalone mode removes etcd but trades away the dynamic configuration workflow that makes APISIX attractive in the first place.

The Lua Plugin Model

APISIX’s extensibility runs through Lua (or an external plugin runner for Go/Python/Java). Lua is fast and battle-tested inside OpenResty, but it’s a niche skill on most application teams. Custom logic means writing, testing, and deploying plugins in a language your product engineers likely don’t use daily — and the external plugin runner adds its own process to operate. This is the core of the semantic vs. programmatic policy tradeoff: expressive custom logic, but in a runtime you have to staff for.

Neither of these is a flaw in APISIX. They’re the inherent cost of a self-operated, Nginx-based gateway. The question is whether that cost buys you something you need — or whether a managed model would free the same engineers to work on your product. Our managed vs. self-hosted decision framework walks through that tradeoff in detail.

What a Fully Managed Alternative Looks Like

If the goal is to keep programmable, per-request control but shed the infrastructure, an edge-native managed gateway is the other end of the spectrum. Zuplo is one example of this model, and it’s a useful point of contrast because it inverts most of APISIX’s operational assumptions:

• No data plane or config store to run. Zuplo is fully managed and serverless across 300+ edge locations. There is no etcd cluster and no Nginx fleet to provision — the gateway runs as V8 isolates at the edge, and deployments propagate globally in under 20 seconds.
• Policies are TypeScript, not Lua. Custom logic is a plain TypeScript function using web-standard Request/Response APIs — the same language your application engineers already use. There’s no separate plugin runner process.
• A developer portal and API key lifecycle are built in. The portal is auto-generated from your OpenAPI spec, with self-serve key creation, rotation, and consumer metadata — no add-on product or custom build.
• API and AI traffic share one engine. Zuplo’s AI Gateway adds multi-provider LLM routing, semantic caching, prompt-injection protection, and budget and token controls, and its MCP Server Handler turns your OpenAPI routes into a Model Context Protocol server — all on the same managed policy engine, rather than a separate AI gateway product.
• Enterprise compliance is first-party. Zuplo is SOC 2 Type II audited, with SAML SSO, SCIM, and RBAC available on Enterprise — compliance that isn’t inherited from an environment you have to harden yourself.

The tradeoff runs the other way too: APISIX supports more L4/L7 protocols natively (MQTT, QUIC, raw TCP/UDP), and a fully managed gateway asks you to trust a vendor with your runtime. Which side of that line you want is the real decision.

APISIX vs API7 Enterprise vs a Managed Gateway

Rather than a feature checklist, here’s how the three models differ on the dimensions that usually decide the evaluation.

Control plane and data plane

• Open-source APISIX: You run both. Config lives in etcd (traditional mode); the Nginx data plane runs on your compute.
• API7 Enterprise / API7 Cloud: API7 Cloud manages the control plane, but the data plane still runs in your infrastructure.
• Managed gateway (e.g., Zuplo): Both control and data plane are fully managed and serverless — nothing to provision.

Policy and extensibility model

• APISIX: 100+ Lua plugins, with Go/Python/Java available via the external plugin runner.
• API7 Enterprise: Same plugin model, plus commercial management tooling.
• Zuplo: TypeScript policies and custom handlers using standard web APIs, version-controlled in Git.

Developer portal and key lifecycle

• APISIX open source: No portal; key auth via plugin, but no self-serve key lifecycle.
• API7 Enterprise: Ships a developer portal with RBAC (commercial product).
• Zuplo: Portal and API key lifecycle built in, not a separate product.

AI and MCP support

• APISIX: Native AI plugins (ai-proxy and ai-proxy-multi for LLM routing, ai-rate-limiting, ai-prompt-guard, and ai-rag) plus MCP-to-HTTP bridging, running on the self-hosted stack; API7.ai also ships AISIX as a separate AI gateway.
• Zuplo: AI Gateway and MCP capabilities on the same managed engine as your API traffic.

Compliance and deployment

• APISIX / API7: Compliance posture inherited from the environment you operate.
• Zuplo: SOC 2 Type II, SAML SSO/SCIM, and sub-20-second global deploys as first-party features.

For the broader field beyond these two, our roundups of the best API gateways in 2026 and top API gateway solutions put more options side by side, and what is an API gateway covers the fundamentals.

Migrating from APISIX: Lua Plugins to TypeScript Policies

The mechanical part of a migration is mapping APISIX concepts onto their managed equivalents. Routes and upstreams become OpenAPI-defined routes; common plugins (rate limiting, key authentication, JWT validation, request transformation) have direct policy equivalents; and bespoke Lua plugins become short TypeScript functions.

Here’s what an APISIX consumer key-auth plugin conceptually maps to. In APISIX, you’d attach the key-auth plugin and manage consumers through the Admin API. In Zuplo, an inbound policy is a TypeScript function that receives the request and either returns it (to continue) or returns a Response (to short-circuit):

import { ZuploRequest, ZuploContext } from "@zuplo/runtime";

export default async function (
  request: ZuploRequest,
  context: ZuploContext,
  options: any,
  policyName: string,
) {
  const apiKey = request.headers.get("api-key");

  if (!apiKey) {
    return new Response("No api-key header", { status: 401 });
  }

  // Continue down the policy pipeline
  return request;
}

Policies are wired up declaratively in config/policies.json and attached to routes, so the configuration stays in Git rather than in a runtime config store:

{
  "policies": [
    {
      "name": "api-key-auth",
      "policyType": "custom-code-inbound",
      "handler": {
        "export": "default",
        "module": "$import(./modules/api-key-auth)"
      }
    }
  ]
}

For most teams, built-in policies cover authentication, rate limiting, and transformation without custom code at all — you only reach for TypeScript when your logic is genuinely bespoke. If you’re moving off a self-operated gateway more broadly, the self-hosted to managed migration guide covers the cutover strategy (parallel-running and weighted routing) in detail.

When APISIX or API7 Is Still the Right Choice

A managed gateway isn’t the answer for everyone. APISIX or API7 remains the better fit when:

• You need broad protocol support — gRPC, MQTT, QUIC, or raw L4 TCP/UDP proxying alongside L7 HTTP. This is APISIX’s strongest differentiator.
• You have deep operational expertise running etcd, Nginx, and Lua, and you value full self-hosted control — including air-gapped or strict data-residency environments where a managed runtime is off the table.
• Your existing investment is heavily in Lua plugins and you’re not ready to consolidate onto a different operating model.

Being honest about these cases is the point: the right gateway depends on whether your team wants to own a runtime or offload it.

FAQ

Is API7 the same as Apache APISIX?

No. Apache APISIX is the open-source gateway, governed by the Apache Software Foundation. API7.ai is the commercial company that created APISIX and sells products on top of it: API7 Enterprise (a self-hosted commercial distribution with a developer portal), API7 Cloud (a managed control plane for a self-hosted data plane), and AISIX (a separate Rust-based AI gateway).

Do I need etcd to run APISIX?

In its traditional deployment mode, APISIX uses etcd as its configuration store, so you operate an etcd cluster alongside the Nginx data plane. APISIX 3.x also offers a standalone mode (file- or API-driven) that runs without etcd, but you give up the dynamic configuration workflow that etcd enables. Either way, you self-host and operate the data plane.

Does Apache APISIX have a developer portal?

Not in the open-source project. Key authentication is available as a plugin, but there’s no built-in developer portal or self-serve API key lifecycle. A portal requires API7 Enterprise (the commercial product) or building one yourself. Managed gateways like Zuplo include a portal and key management as a built-in part of the platform.

Does APISIX have AI gateway and MCP features?

Yes. APISIX added native AI plugins (ai-proxy and ai-proxy-multi for LLM routing, ai-rate-limiting, ai-prompt-guard, and ai-rag) plus MCP-to-HTTP bridging, all running on its self-hosted Lua/Nginx stack, and API7.ai ships AISIX as a separate AI gateway. The difference with a managed platform is delivery: API and AI traffic run on one gateway you don’t operate.

How hard is it to migrate from APISIX?

Routes and upstreams map to OpenAPI-defined routes, and common plugins (rate limiting, key auth, JWT validation, transforms) have direct equivalents or short custom-code replacements. Bespoke Lua plugins are rewritten as TypeScript functions. Most teams run both gateways in parallel and shift traffic gradually with weighted routing before decommissioning the old data plane.

Conclusion

Apache APISIX gives you a powerful, protocol-rich gateway — and, in exchange, an etcd cluster, an Nginx data plane, and a Lua plugin model to operate. API7’s commercial products soften parts of that (a portal in Enterprise, a managed control plane in Cloud), but every APISIX path leaves some runtime in your hands.

If that operational ownership is a feature for your team, APISIX is an excellent choice. If it’s a tax you’d rather not pay, a fully managed, TypeScript- programmable gateway keeps the per-request control while removing the infrastructure entirely.

Want to see the managed model in practice? Try Zuplo for free and deploy a globally distributed, programmable API gateway in minutes — no etcd, no Lua, no data plane to run.