OpenResty

What it is

OpenResty bundles Nginx with LuaJIT and a set of Lua libraries, letting you write request-handling logic — routing, auth, rate limiting, header manipulation, upstream selection — directly in Lua inside the Nginx request lifecycle. It's the engine underneath a lot of API gateways and edge proxies (Kong and APISIX are both built on it). Rather than compiling a custom Nginx module in C, you write Lua and hot-reload it. Official category tag here says "Orchestration & Management," but in practice it sits lower in the stack — it's an extensible reverse proxy / web application server, not an orchestrator in the Kubernetes-controller sense.

Who builds it and why

Originally driven by Yichun Zhang ("agentzh"), who built it out of work at Taobao to handle Nginx's scripting gaps at scale. It's remained a small, focused C/Lua codebase rather than a broad community project — 43 contributors is a lean number for a project this widely deployed, which tells you it's maintained by a small core group of people who deeply understand the Nginx internals, not a sprawling foundation-backed effort. Founding date isn't publicly documented, but the project has been circulating in production infra since the early 2010s.

Production readiness signal

Active. Last commit July 2026, current release v1.27.1.2 — versioning follows Nginx's own numbering closely, which is typical for this project. 13,921 GitHub stars reflects wide indirect adoption (much of it inherited through Kong/APISIX rather than direct OpenResty deployments). CNCF maturity level is not publicly available — OpenResty itself is not a CNCF project; the confusion often comes from CNCF projects built on top of it. License shows as NOASSERTION in repo metadata, which means the license isn't cleanly machine-readable from the repo — worth manually verifying the actual license terms (historically BSD) before using it in anything with legal review requirements.

Who should use this

• Teams building a custom API gateway or edge proxy and want programmable request/response logic without patching Nginx C source.
• Platform teams already running Kong, APISIX, or Tyk who need to understand the layer underneath for debugging or writing custom plugins.
• Anyone needing sub-millisecond scripting overhead at the proxy layer — LuaJIT is fast, and this is why it's the substrate for so many gateways instead of Node or Python-based proxies.

Who should NOT use this

• Teams wanting a managed, GUI-driven API gateway out of the box — use Kong or APISIX directly instead of building on raw OpenResty.
• Anyone expecting Kubernetes-native orchestration (ingress controllers, operators, autoscaling) — despite the category label, OpenResty does none of that natively; you'd pair it with something else or use an ingress controller that embeds it (like ingress-nginx, which is a different codebase).
• Organizations without Lua expertise on staff — debugging Lua running inside Nginx's event loop has a real learning curve, and the small contributor base means community-sourced help is thinner than for mainstream proxies like Envoy.
• Teams needing strict, auditable licensing — the NOASSERTION license flag in the repo is a blocker for some legal/compliance review processes until manually resolved.

Alternatives

• Envoy — C++ proxy with a broader ecosystem, native gRPC/xDS support, and CNCF graduated status; better fit if you need dynamic config via control plane rather than embedded scripting.
• HAProxy — simpler, extremely fast L4/L7 proxy with a Lua scripting option too, but a smaller extensibility model than OpenResty's full Nginx+Lua integration.
• Kong / APISIX — both are built on OpenResty but give you a plugin architecture, admin API, and dashboard instead of requiring you to script the proxy layer yourself.

Pricing

Fully open source, no paid tier. Cost is entirely in engineering time to build and maintain Lua-based proxy logic — there's no vendor, no support contract, no hosted option from the project itself.