Apache APISIX: Is This the API Gateway You Should Actually Be Running in Production?
The Momentum Is Real — But So Is the Complexity
APISIX has been on a steady upward trajectory for a while now, and the recent commit velocity confirms it isn't slowing down. In the past week alone: a TLS vulnerability fix, credential-leaking log statements patched across multiple plugins, brotli header preservation, and new expression-based AI rate limiting. That's not a project coasting on star count — that's an actively maintained piece of infrastructure. With 16,400+ stars, 2,800+ forks, and a core team that's been pushing commits since 2019, this is a mature project that deserves a serious look if you're evaluating API gateways.
But "mature" doesn't automatically mean "right for you." Let me give you the unfiltered version.
What APISIX Actually Is
At its core, APISIX is an API gateway built on top of Nginx and OpenResty, written primarily in Lua (LuaJIT specifically). It sits in front of your services and handles everything you'd expect from a gateway: routing, load balancing, auth, rate limiting, observability, SSL termination — plus a plugin system that extends it significantly.
What sets it apart from something like Kong (which shares the same Nginx/OpenResty foundation) is its configuration model. APISIX uses etcd as its configuration store, which means config changes propagate in real time without reloads or restarts. Routes, upstreams, plugins — all of it is hot-reloadable. If you've ever had to gracefully reload Nginx at scale and held your breath, you'll appreciate what this means in practice.
It also positions itself increasingly as an "AI Gateway" — proxying LLM APIs, load balancing across multiple AI providers, token-based rate limiting, and even bridging stdio-based MCP servers to HTTP/SSE. That's not just marketing; the commit history shows real work going into ai-proxy-multi, ai-rate-limiting, and related plugins.
Why This Matters Right Now
The API gateway space is crowded. You've got Kong, Traefik, Envoy, AWS API Gateway, nginx-ingress, and a dozen others. So why does APISIX matter?
A few reasons:
The etcd-backed dynamic config model is genuinely differentiated. Most gateway solutions require some form of reload or restart to apply config changes. APISIX doesn't. For teams running high-throughput production traffic where a reload means dropped connections or a brief blip, this matters.
The plugin ecosystem is deep and growing. We're talking 80+ plugins covering auth (JWT, HMAC, OIDC, Casbin, Keycloak), observability (Prometheus, Datadog, SkyWalking, OpenTelemetry), traffic control, transformations, and more. The recent addition of AI-focused plugins reflects where infrastructure is heading.
Kubernetes-native without being Kubernetes-only. It runs as a k8s ingress controller via the separate apisix-ingress-controller project, but it also runs fine on bare metal or VMs. That flexibility is underrated when you're dealing with mixed environments.
The Apache foundation backing means longevity. This isn't a VC-funded startup that might pivot or get acqui-hired. Apache projects have a track record of sticking around.
Features Worth Calling Out
1. Hot Plugin Updates Without Restarts This is the headline feature and it actually works as advertised. You can add, modify, or remove plugins on live routes without any service interruption. For teams doing continuous delivery on gateway config, this is a genuine quality-of-life improvement.
2. Fine-Grained Routing APISIX's routing is built on a radix tree implementation that supports full Nginx variable access as routing conditions. You can route based on cookies, query params, headers, geographic data — whatever Nginx exposes. This makes canary releases and A/B testing at the gateway layer actually practical rather than a hack.
3. Multi-Protocol Support HTTP/HTTPS is table stakes. APISIX also handles gRPC (including transcoding HTTP/JSON to gRPC), WebSocket, MQTT, TCP/UDP stream proxying, and now HTTP/3 with QUIC. If you have a heterogeneous service landscape — and most production environments do — this breadth matters.
4. Built-In Observability Out of the box you get Prometheus metrics, support for distributed tracing via SkyWalking and OpenTelemetry, and multiple logging plugins. The observability story is solid enough that you won't need to bolt on a separate solution just to get visibility into what's happening at the gateway layer.
5. The AI Gateway Pivot Is Substantive
I was skeptical of the "AI Gateway" branding at first — it smells like trend-chasing. But looking at the actual commits, the ai-proxy-multi plugin, token-based rate limiting, and the MCP bridge plugin represent real functionality. If you're routing traffic to OpenAI, Anthropic, or self-hosted LLMs and want centralized auth, rate limiting, and fallback logic at the gateway layer, APISIX is one of the few options that has actually built this out rather than just claimed it.
Who Should Use This
You should seriously consider APISIX if: - You're running microservices at non-trivial scale and need a gateway that can handle config changes without restarts - You're already invested in the Kubernetes ecosystem and want a gateway that integrates cleanly as an ingress controller - You need multi-protocol support beyond just HTTP — gRPC, MQTT, TCP/UDP - You want a self-hosted, open-source gateway with genuine enterprise-grade features without paying Kong's licensing fees - You're building AI-native infrastructure and want centralized LLM traffic management
You should probably look elsewhere if: - Your team has zero Lua experience and no appetite to learn it for custom plugin development. Writing custom plugins means writing Lua, and the OpenResty ecosystem has a learning curve that isn't trivial. - You want a fully managed solution. APISIX is self-hosted. etcd is a dependency you need to operate. That's real operational overhead. - You're a small team with a simple use case. If you have 3 services and basic routing needs, APISIX is overkill. Traefik or even a well-configured nginx will serve you better. - You need first-class Windows support. This is a Linux-native project.
Honest Concerns
The Lua barrier is real. APISIX's extensibility is one of its strengths, but it comes with a cost: if you need custom plugin logic, you're writing Lua. Most backend developers don't know Lua, and while it's not a hard language, it's yet another thing to learn and maintain. Kong has the same problem. If your team is Go or Python-native, budget time for this.
etcd as a dependency adds operational complexity. etcd is a solid piece of software, but it's another distributed system to run, monitor, back up, and keep healthy. If etcd has a bad day, your gateway config won't update. For teams already running Kubernetes (which uses etcd internally), this is less of an issue, but it's worth acknowledging.
The security fix cadence is a double-edged sword. I noticed the recent commits include fixes for credential-leaking log statements in multiple plugins and TLS vulnerabilities. On one hand, this shows the team is actively finding and fixing security issues. On the other hand, it means you need to stay on top of upgrades. Running a version that's a few releases behind could mean running with known vulnerabilities. The flip side: a gateway that never has security fixes is one that isn't being audited.
Documentation quality is uneven. The core documentation is solid, but plugin docs vary in quality and completeness. Some plugins are well-documented with examples; others have sparse docs that leave you reading source code to understand behavior. This is a common Apache project problem and not unique to APISIX, but it's a real friction point.
The admin API is powerful but not secured by default in all configurations. The recent commit making /configs/validate available in all modes hints at ongoing work here. Make sure you understand the admin API security model before you expose this in any environment.
250 open issues is a reasonable number for a project of this scale, but scan them before committing. Some edge cases around specific plugin combinations and certain Kubernetes configurations have been open for a while.
The Verdict
APISIX is a serious, production-grade API gateway that earns its star count. The hot-reload architecture, deep plugin ecosystem, and multi-protocol support put it in a different class from simpler reverse proxies. The active commit history and security responsiveness give me confidence that adopting it isn't betting on abandonware.
That said, it's not a drop-in solution. The Lua ecosystem, etcd dependency, and operational complexity mean this is a tool for teams that are ready to invest in running it properly. If you're evaluating it against Kong, the main differences come down to: APISIX is fully open-source (no enterprise tier paywall for core features), uses etcd instead of PostgreSQL, and has a slightly more active upstream community right now.
If you're running microservices at scale, already operating Kubernetes, and need a gateway that can genuinely keep up with your deployment velocity without becoming a bottleneck — APISIX is worth the investment. If you're looking for something you can set up in an afternoon and forget about, look at Traefik or Caddy instead.
My personal take: I'd run this in production. The team is clearly doing the right things — fixing security issues promptly, refactoring for maintainability, and building features that reflect where the industry is actually going. The AI gateway work in particular is more substantive than I expected. Just make sure you have someone on the team who's willing to get comfortable with Lua and etcd operations before you commit.