Apache APISIX: A Serious Nginx-Based API Gateway That's Actually Worth Your Attention
The Momentum Is Real
16,400+ stars, commits landing daily, a v3.16.0 release just last week, and a trend status marked as rising — Apache APISIX isn't a side project someone abandoned after a conference talk. It's been in active development since 2019, it's a top-level Apache project, and the commit history shows a team that's fixing real bugs (credential-leaking log statements, TLS vulnerabilities) while also shipping new features. That combination of maintenance hygiene and forward momentum is something you don't always find in the API gateway space, and it's the first thing that caught my attention.
Let me be clear upfront: I'm not here to sell you on this. I'm here to give you my honest read on whether it's worth the time investment to evaluate it seriously.
What APISIX Actually Is
At its core, APISIX is an API gateway built on top of OpenResty (Nginx + LuaJIT). If you've used Kong, you already understand the basic architecture — except APISIX uses etcd instead of PostgreSQL as its configuration store, which has meaningful implications for how it behaves in distributed deployments.
What makes APISIX different from "just configure Nginx yourself" is the dynamic configuration layer. You don't reload Nginx to change routes, upstream targets, or plugin configurations. Changes propagate in real time via etcd watch, which means zero-downtime config updates without the operational pain of managing Nginx reload cycles across a cluster. That alone is worth something.
The plugin system is where most of the value lives. There are 80+ built-in plugins covering authentication (JWT, key-auth, OIDC, HMAC), rate limiting, observability (Prometheus, Datadog, OpenTelemetry), traffic management (canary releases, traffic mirroring, circuit breaking), and a growing set of AI-specific plugins. The recent commits show active work on AI proxy features — multi-LLM load balancing, token-based rate limiting, expression-based rate limiting strategies. The "AI Gateway" positioning isn't just marketing; there's actual code behind it.
Why This Matters Right Now
The API gateway space has a problem: most of the mature options come with significant trade-offs. Kong is powerful but the open-source version is increasingly crippled compared to the enterprise offering, and the PostgreSQL dependency adds operational overhead. Envoy is excellent but the configuration model is not friendly to humans — you're basically writing YAML for a C++ proxy and hoping the xDS API does what you think it does. AWS API Gateway works until you need to do anything non-standard or want to avoid vendor lock-in. Traefik is great for simple cases but starts to show limitations at scale.
APISIX fills a gap: a genuinely open-source (Apache-licensed, no enterprise gating), high-performance gateway that doesn't require a PhD in distributed systems to operate, but also doesn't fall apart when you need advanced routing logic or custom plugins.
The timing matters too. With LLM APIs becoming a real infrastructure concern, the need to put a proper gateway in front of OpenAI/Anthropic/etc. — for rate limiting by token count, fallback routing, cost attribution — is a real problem teams are solving right now. APISIX is one of the few gateways actively building for this use case rather than bolting on an AI label.
Features Worth Calling Out
1. Hot-reload everything Routes, upstreams, certificates, plugins — all of it updates without restarting the gateway. This sounds basic but it's operationally significant. In production, the ability to rotate a TLS certificate or add a new upstream without a service interruption is not a nice-to-have.
2. The plugin system is actually extensible You can write custom plugins in Lua, and the plugin execution lifecycle is well-defined (rewrite, access, header_filter, body_filter, log phases). If you know Lua or are willing to learn enough of it, you can do genuinely complex things. There's also a plugin runner interface that lets you write plugins in Go, Python, or Java if Lua isn't your thing — though I'd treat that as a fallback, not a first choice, since the performance characteristics differ.
3. etcd-based configuration is a double-edged sword (but mostly good) Using etcd means APISIX fits naturally into Kubernetes environments where etcd is already present. The configuration propagation is fast and consistent. The downside is that etcd is another dependency to operate, and if you're running this outside Kubernetes, you need to think about etcd availability. It's not a dealbreaker, but it's a real operational consideration.
4. Protocol support is genuinely broad HTTP/1.1, HTTP/2, HTTP/3/QUIC, gRPC, gRPC-Web, WebSocket, TCP/UDP stream proxying, MQTT — this isn't a gateway that forces you to put a different proxy in front of it for each protocol. For teams running mixed workloads (REST APIs, gRPC microservices, IoT devices), having one gateway that handles all of it is a legitimate operational simplification.
5. Kubernetes integration without a full service mesh The apisix-ingress-controller project gives you a proper Kubernetes ingress controller backed by APISIX. If you want the power of a full-featured gateway as your ingress without adopting Istio or Linkerd, this is a reasonable path. It's not as deeply integrated as something like Cilium, but it's significantly more capable than nginx-ingress for complex routing scenarios.
Who Should Use This
Good fit: - Teams running microservices on Kubernetes who need more than nginx-ingress but aren't ready for a full service mesh - Organizations that need a genuinely open-source gateway without enterprise licensing concerns - Teams putting gateways in front of LLM APIs and needing token-aware rate limiting and multi-provider load balancing - Anyone currently running Kong who's frustrated with the open-source vs. enterprise feature gap - Teams with Lua expertise or willingness to write Lua for custom plugins
Not a good fit: - Small projects where "configure Nginx manually" is genuinely sufficient - Teams that need a fully managed, zero-ops gateway (use AWS API Gateway or similar) - Organizations where Lua is a hard no from a security review perspective - Teams that need a GUI-first experience — APISIX's dashboard exists but it's not the primary interface and it shows
Honest Concerns
Lua is a barrier. I'll be direct: most backend developers in 2025 don't know Lua. The plugin system is powerful, but writing and debugging Lua in an OpenResty context requires understanding how LuaJIT works, how the Nginx request lifecycle maps to Lua coroutines, and how to avoid blocking the event loop. The learning curve is real. The plugin runner approach (Go/Python/Java) mitigates this but adds latency overhead.
Documentation quality is uneven. The main docs are solid for common use cases, but once you get into edge cases or advanced plugin configuration, you'll find yourself reading source code and GitHub issues more than documentation. This is a common Apache project problem and it's not unique to APISIX, but it's worth knowing going in.
etcd dependency. If you're running outside Kubernetes, standing up a production-grade etcd cluster is non-trivial. APISIX does support a standalone mode now, but the full feature set assumes etcd. For teams without existing etcd experience, this is an operational investment.
The "AI Gateway" positioning is early. The AI proxy plugins are actively developed and functional, but this is a young feature area. If your primary use case is AI gateway functionality, I'd evaluate the specific plugins carefully against your requirements rather than assuming feature completeness.
Community support has a geographic skew. The project originated in China, and a significant portion of the community and documentation is oriented toward that ecosystem (Alibaba Cloud, Nacos, Dubbo integrations). This isn't a problem per se, but if you're in a Western enterprise environment, you may find less community overlap with your specific stack.
Verdict
APISIX is a legitimate, production-ready API gateway that deserves serious consideration if you're in the market. It's not a toy project — the commit history, the contributor base, the Apache governance, and the feature depth all point to something that's been battle-tested.
If I were evaluating gateways today for a Kubernetes-based microservices environment, APISIX would be on my shortlist alongside Kong and potentially Envoy. The hot-reload configuration model, the broad protocol support, and the genuinely open plugin system give it real advantages. The Lua learning curve and etcd dependency are the main things I'd want to pressure-test in a proof of concept before committing.
For teams already deep in the Nginx/OpenResty ecosystem, this is almost a no-brainer. For everyone else, it's worth a week of evaluation time. The project is actively maintained, the community is responsive, and the Apache license means you're not going to get surprised by a license change that forces a migration.
Go kick the tires. Just make sure someone on your team is willing to learn enough Lua to write a plugin when you inevitably need one.