---
title: "Managed Apache APISIX: A Guide to APISIX, API7 Enterprise, and Fully Managed Alternatives"
description: "How Apache APISIX, API7 Enterprise, and API7 Cloud differ — and how a fully managed, TypeScript-programmable gateway removes the etcd and Lua operational tax."
canonicalUrl: "https://zuplo.com/learning-center/managed-apache-apisix-api7-alternatives"
pageType: "learning-center"
authors: "nate"
tags: "API Gateway"
image: "https://zuplo.com/og?text=Managed%20Apache%20APISIX%20and%20API7%20Alternatives"
---
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?](#is-api7-the-same-as-apache-apisix)
- [How APISIX Is Architected](#how-apisix-is-architected)
- [The Three Ways to Run APISIX](#the-three-ways-to-run-apisix)
- [Where the Operational Tax Comes From](#where-the-operational-tax-comes-from)
- [What a Fully Managed Alternative Looks Like](#what-a-fully-managed-alternative-looks-like)
- [APISIX vs API7 Enterprise vs a Managed Gateway](#apisix-vs-api7-enterprise-vs-a-managed-gateway)
- [Migrating from APISIX: Lua Plugins to TypeScript Policies](#migrating-from-apisix-lua-plugins-to-typescript-policies)
- [When APISIX or API7 Is Still the Right Choice](#when-apisix-or-api7-is-still-the-right-choice)
- [FAQ](#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](/learning-center/control-plane-vs-data-plane-api-gateway)
and
[API gateway plugin architectures](/learning-center/api-gateway-plugin-architectures-compared).

## 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](/learning-center/semantic-vs-programmatic-api-gateway-policies)
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](/learning-center/managed-vs-self-hosted-api-gateway)
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](https://zuplo.com) 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](https://zuplo.com/ai) adds multi-provider LLM routing, semantic
  caching, prompt-injection protection, and budget and token controls, and its
  [MCP Server Handler](https://zuplo.com/docs/mcp-server/introduction) 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](/learning-center/best-api-gateways-2026) and
[top API gateway solutions](/learning-center/top-api-gateway-solutions) put more
options side by side, and
[what is an API gateway](/learning-center/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):

```typescript
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:

```json
{
  "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](/learning-center/migrate-self-hosted-to-managed-api-gateway)
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](https://zuplo.com)
and deploy a globally distributed, programmable API gateway in minutes — no etcd,
no Lua, no data plane to run.