Thinking about the next 15 years: A discussion on APISIX’s architectural foundations (OpenResty/Nginx/LuaJIT)

[mcarbonneaux]

Hi everyone,

I am currently evaluating several API Gateway solutions (APISIX, Kong, and Envoy-based gateways) for a massive infrastructure overhaul. My goal is to replace a custom, home-made API Gateway that has been in production for 15 years. To give you an idea of the scale, this legacy system currently handles over 110 billion API calls per years. Since our next choice will anchor our infrastructure for the next decade or more, I am performing a deep dive into the long-term viability and "supply chain" health of each project.

While APISIX offers an impressive feature set, I’d like to start a transparent discussion on a few strategic points regarding its architectural foundations:

1. The "Post-F5" Nginx & OpenResty Reality

Nginx has been a rock-solid backbone for years. However, since the F5 acquisition and the departure of its original founders, the Open Source project appears to be in a more conservative "maintenance mode." Similarly, OpenResty has a very high "bus factor" and has seen limited core activity recently. For a project intended to last another 15 years at a scale of billions of requests, is it risky to remain tied to an upstream foundation that is no longer the primary driver of networking innovation?

2. The Stagnation of LuaJIT and Talent Scarcity

APISIX’s performance is world-class, but it relies heavily on LuaJIT. Beyond the fact that LuaJIT development is largely stagnant, there is a significant human factor: it is becoming increasingly difficult to find experts who can develop, debug, and optimize complex logic in Lua within an asynchronous Nginx environment. Most modern engineering talent is gravitating toward Go, Rust, or Wasm. How does APISIX plan to address this talent gap and the "frozen" nature of its runtime over the next decade?

3. Native Support for Modern Protocols (gRPC & AI/MCP)

We are entering an era of deep, stateful, and bi-directional streaming:

• Advanced gRPC: Requirements for native transcoding (REST to gRPC), trailers-based observability, and hedging.
• AI-Native Streaming: Protocols like MCP (Model Context Protocol) require managing long-lived, complex JSON-RPC sessions.

While I know these can be implemented via Lua plugins, I am concerned about the architectural overhead and technical debt of managing these modern, stateful requirements on top of a legacy web-server model.

My question to the maintainers:
If you were in my position, looking to migrate a system handling 110 billion calls per years to a solution that must remain "up-to-date" until 2040, how do you see the evolution of the APISIX Data Plane? Is there a roadmap to eventually decouple from these aging dependencies (Nginx/LuaJIT) or to move toward a more modern, community-driven engine?

I am looking for a solution that is as future-proof as possible, and I’d love to hear your vision for the next 15 years of APISIX.

Best regards,
Mathieu

[moonming]

Hi @mcarbonneaux,

Thank you for raising this discussion publicly — these are exactly the right questions to ask when choosing infrastructure for the next 15 years, and I believe the APISIX community benefits from discussing them transparently.

Full disclosure: I'm the PMC Chair of Apache APISIX and one of its original creators, so my perspective inevitably carries personal bias. I'll try to be as honest as I can.

1. Nginx and OpenResty
   You're right to think about this. While both Nginx and OpenResty continue to receive updates and new releases, neither belongs to a neutral foundation — they are ultimately controlled by commercial entities. If we look 15 years ahead, there is a real possibility that either project could stop being maintained or change its licensing terms. For APISIX, that would be a supply chain risk. We are aware of this and need to prepare for it proactively.

2. LuaJIT
   This is arguably the more urgent concern. LuaJIT has an extremely high maintenance barrier and an even smaller pool of active contributors than OpenResty. I won't sugarcoat this — it's a real challenge.

3. Plugin Development
   On this point, I'm actually less worried. Writing Nginx modules and APISIX plugins is well-documented, there are plenty of open-source examples to reference, and AI-assisted coding has made this significantly easier. As long as we're not modifying core internals, plugin development is manageable.

4. The Path Forward
   APISIX has already taken some steps here — we support writing plugins in Go, Java, and Wasm, not just Lua. But these external plugin runners don't solve every problem. For features like native gRPC handling or new AI-related protocols, we need changes at the core level — and that means depending on Nginx and OpenResty upstream, which is exactly the bottleneck you identified.

My long-term vision is to introduce Rust as an embedded layer within APISIX. Rust would handle the areas where we're currently blocked by upstream dependencies — gRPC, AI-native features, and modern protocol support — without requiring a full rewrite of APISIX's core architecture. This gives us a pragmatic path: keep the battle-tested Nginx/Lua foundation for what it does well, while using Rust to break through the ceiling where that foundation falls short.

This isn't about replacing everything overnight. It's about making sure APISIX can keep pace with what users need from an API Gateway and AI Gateway over the next decade, without being held hostage by upstream decisions we don't control.

Mathieu, what does your ideal evolution path look like? I'm curious whether you see a gradual, hybrid approach like this as practical, or whether you'd prefer a cleaner break from the Nginx/Lua stack entirely.

[juzhiyuan]

I won’t comment on the other parts, but on the developer-friendliness aspect, one thing that deserves recognition is that the source code of many built-in apisix lua plugins is itself a major reason why many developers and enterprise users appreciate APISIX. https://github.com/apache/apisix/tree/master/apisix/plugins

For requirements that can be reasonably addressed through the plugin mechanism, users are not limited to black-box features. They can study how built-in plugins are implemented, learn from real production-grade examples, and now even use LLMs to accelerate their understanding of the development workflow.

[mcarbonneaux]

Thank you for these incredibly honest and transparent answers. It is rare and refreshing to see project leadership acknowledge the "supply chain risk" of its own foundations (OpenResty/LuaJIT) so clearly.

I completely agree that the built-in plugins are APISIX's greatest asset. They represent a goldmine of production-grade logic. However, looking at the next 15 years, the critical challenge is: How do we preserve this immense functional value while migrating to a core that the next generation of engineers can actually maintain?

The "Frankenstein" Risk & The Talent Gap

While the plan to embed Rust to bypass Nginx limitations is technically exciting, I have a major concern regarding the human factor and architectural debt.

• The Talent Gap: In terms of code safety, Rust is a masterpiece. But in terms of community maintenance, Rust might become the "new Lua." Compared to the massive Go ecosystem, Rust experts are rare and have a notoriously steep learning curve.
• The "Maintenance Trap": Most importantly, adding Rust to Nginx is still maintaining Nginx. It doesn't solve the "supply chain risk" or the conservative maintenance mode of the F5-controlled core. It simply adds a layer of complexity (FFI, memory management across boundaries) to an aging foundation. By doing this, you are "decorating the prison" rather than moving to a more open, modern environment.

If we want APISIX to be the standard in 2040, we should aim for a foundation that the average cloud-native engineer can contribute to.

Two Strategic Paths for the Next Decade

1. The "Sovereign Core" (Go/Lura + Lua VM)

Instead of adding external runners that introduce latency, APISIX could evolve toward a core based on Lura (CNCF).

• The KrakenD / GopherLua Example: A great precedent for this is KrakenD Enterprise. They leverage the Lura engine (Go) and provide Lua 5.1 support via GopherLua (a 100% native Go implementation of Lua).
• The Advantage: By using a native Go implementation of the Lua VM, you eliminate the "black box" of LuaJIT's (go can call natively luajit also...) C/Assembly internals. Any Go developer can debug the entire stack.
• The Bridge: APISIX could implement its signature Radix Tree routing into a Go-based core while keeping a Lua compatibility layer for its 100+ existing plugins.

2. The "Ecosystem Play" (Control Plane for AI-Native Envoy)

A cleaner break from the "web-server" legacy, especially considering the rise of AI Gateways:

• The Move: Pivot APISIX into a sophisticated Meta-Operator (potentially leveraging frameworks like kro.run).
• The Strategy: Envoy Gateway is moving fast on AI-native features (LLM providers integration, token-based rate limiting, prompt caching). By becoming a top-tier Control Plane for Envoy, APISIX could focus 100% of its energy on orchestration, AI-specific logic, and user experience, while delegating the heavy lifting of modern protocols (gRPC, HTTP/3, AI streaming) to a massive CNCF-backed Data Plane.

Conclusion

I’m curious: is the Rust-patch approach considered a permanent bridge, or is there a long-term appetite within the PMC for a deeper architectural shift (like moving to a Go or Envoy-based core)?

Pragmatically, I believe that a "clean break" toward a foundation with a larger talent pool and CNCF governance is the only way to ensure APISIX doesn't become a "legacy" project itself by 2035.

[mcarbonneaux]

To contribute to the debate about the evolution from LuaJIT towards more modern ecosystems like Go or Rust, here are a few industry examples and technical points on why Go is a strategic candidate for APISIX’s next decade:

1. The "De Facto" Cloud Standard

The entire modern infrastructure stack is built on Go: Kubernetes, Docker, and Podman are all Go-based. It’s where the talent, the libraries, and the community are. Many industry leaders are already making this shift for better maintainability, as seen in [WSO2’s transition from Java to Go](https://wso2.com/library/blogs/goodbye-java-hello-go/).

2. Pragmatic Migration: The GopherLua Bridge

We don't have to break the ecosystem. A Go-based architecture offers a unique, incremental path for transition:

• The ext_proc Strategy: We can build an ext_proc (External Processing) service in Go that embeds GopherLua. This allows Envoy to offload the execution of existing APISIX Lua plugins to a specialized Go process.
• Legacy Preservation: This ensures 100% backward compatibility while moving away from the "FFI sandwich" and the "Stop-the-World" GC issues of LuaJIT.
• Native Evolution: Over time, these Lua scripts can be replaced by Native Go (using the exhaustive standard library) or WASM (TinyGo) without changing the core architecture.

3. The Strategic Crossroads: Envoy vs. Native Go

Whether APISIX chooses to build a native Go engine (like KrakenD) or orchestrate Envoy, Go remains the superior choice:

• Full-Stack Go: Every component—Control Plane, Meta-Operators, ext_authz, and WASM filters—can be unified under a single language.
• Native Concurrency: Go’s Goroutines provide a native $N:M$ scheduling model. While Rust is powerful, its concurrency (Tokio) is an external dependency, and it often remains tied to OpenSSL via FFI. Go provides a memory-safe, native implementation for the entire networking stack (HTTP/2, TLS, SQL, JSON, Crypto) out of the box.
• Operational Simplicity: One static binary, no sidecar overhead, and deep profiling with pprof.

4. Modern Extensibility & Multi-Runtime Support

A Go core opens the door to a multi-tiered extension model that LuaJIT cannot match:

• GopherLua: A pure Go Lua 5.1 VM to run legacy plugins safely, without CGO or memory corruption risks.
• WASM (TinyGo): For isolated, high-performance plugins. A Go host can natively expose its internal stack (context, shared data, internal channels) to WASM modules.
• Interpreted Go (Yaegi): For a dynamic, scripted experience using Go syntax for plugins, without leaving the ecosystem.
• CEL (Common Expression Language): For ultra-fast and safe policy evaluation (RBAC, routing) without the overhead of a full scripting VM.

Conclusion

By adopting Go, APISIX can move from a "scripts-on-top-of-C" model to a modern, type-safe, and highly concurrent platform. Aligning with the Go + WASM ecosystem is the most pragmatic way to attract the next generation of contributors and maintain leadership for the next 15 years.

[mcarbonneaux]

In other to ensure APISIX remains the leader for the next decade, we should consider a strategic shift toward a Go-based Control Plane orchestrating an Envoy-based Data Plane. This approach provides a pragmatic bridge between our Lua heritage and the modern Cloud-Native ecosystem.

1. Native Efficiency: Envoy Filters vs. Lua Plugins

By adopting Envoy, we can offload 60% of current Lua plugins (JWT, Rate-limiting, CORS, Observability) to native C++ filters. This drastically reduces CPU overhead and eliminates the "Stop-the-World" Garbage Collection pauses inherent to LuaJIT, making the gateway significantly more predictable under high load.

2. GitOps-Ready with Envoy Gateway

Transitioning to an Envoy Gateway model makes APISIX GitOps-native by default. Using Go to build the APISIX Controller (or a Meta-Operator) allows us to:

• Leverage the Go-Control-Plane library to manage Envoy fleet configurations dynamically.
• Align perfectly with the Kubernetes ecosystem (K8s Gateway API).
• Provide a seamless developer experience where infrastructure is defined as code, managed by the same Go-based tools used by the rest of the CNCF stack.

3. Preserving the Lua Legacy: The ext_proc Strategy

We don't need to abandon our existing 80+ plugins. We can maintain complex or proprietary logic by wrapping it in a Go-based ext_proc (External Processing) service:

• High Performance: Use LuaJIT via CGO inside the ext_proc for raw speed.
• High Safety: Use GopherLua (pure Go) for simpler, non-critical plugins.
• Decoupling: This isolation ensures that a faulty Lua script cannot crash the main traffic engine, while providing a clear path to gradually rewrite logic into Native Go or WASM.

4. Future-Proofing with AI Envoy Gateway

The rise of AI requires specialized gateway capabilities (Prompt Guard, AI Rate-limiting, LLM Caching). By moving to Go/Envoy:

• We can leverage the Envoy AI Gateway filters directly.
• We can use Go's superior Standard Library (gRPC, JSON, advanced Crypto) to orchestrate AI workflows and vector database integrations far more effectively than Lua ever could.

Conclusion: Why Go is the Only Pragmatic Choice

While Rust offers memory safety, Go is the language of the Cloud infrastructure. By building the new APISIX Controller and Meta-Operators in Go, we attract a massive pool of contributors and ensure perfect integration with the tools that define modern DevOps.

This architecture—Go for Control, Envoy for Speed, and WASM/ext_proc for Flexibility—is the blueprint for APISIX's continued leadership for the next 15 years.