OpenResty: Nginx as a Scriptable Web Platform

What OpenResty bundles and who the bundle is for

The README describes OpenResty as a web application server assembled by bundling the standard nginx core, a large set of third-party nginx modules, and most of those modules' external dependencies. The bundle is maintained by Yichun Zhang. The stated reason for shipping everything together is coordination: because most of the bundled modules are developed by the bundle maintainers, the project can ensure the modules work together. That is the actual product. OpenResty is not a fork of nginx with a rewritten core; it is a distribution of nginx plus modules plus the LuaJIT runtime, versioned as a unit.

The audience is split in two by the README itself. Users are pointed at the download page and the installation page on openresty.org. Bundle maintainers, meaning people who want to reproduce the tarball from source, are pointed at the git repository and told to run make at the top of the source tree. If you are evaluating OpenResty as a deployment target, the first path applies to you and the second does not. The distinction matters because the repository you are reading is the bundle recipe, not the installable artifact.

How the bundle is assembled and what resolv.conf parsing adds

The top level of the repository holds the pieces of that recipe: a Makefile, a util directory, patches, specs, tests under t, and directories for clients, demo, doc, and html. The Makefile's default target is all, which runs ./util/mirror-tarballs. That is the mechanism by which the bundle is reproduced: the source tree does not contain the vendored nginx core and modules directly, it contains the tooling to fetch and assemble them into an openresty-<version> directory. The Makefile's own try-luajit target depends on all, then changes into that generated directory and runs ./configure --with-luajit. So the LuaJIT integration is a configure flag on the assembled tree, not something baked into this repository's C sources.

On top of the standard nginx core, the README documents one additional feature: the resolver directive accepts a local= parameter that parses nameservers from a file in resolv.conf format. The syntax is resolver address ... with optional valid=time, ipv6=on|off, and local=on|off|path, valid in http, stream, server, and location contexts. local=on uses /etc/resolv.conf; local=off disables parsing and is the default; local=/tmp/test.conf reads an arbitrary path. Two constraints are stated plainly. IPv6 nameservers carrying a zone ID, such as fe80::1%eth0, are skipped with a warning, and if no usable nameservers remain after that, including any explicitly configured addresses, configuration fails rather than starting with an empty resolver set. This feature is not available on Windows platforms.

Building OpenResty from the bundle source

The README gives the bundle-maintainer path explicitly. At the top of the bundle source tree, run make. The Makefile's all target invokes ./util/mirror-tarballs, which produces the openresty-<version> directory that the later targets operate on. The README warns that extra dependencies may be needed, naming perl, dos2unix, and mercurial, and gives Fedora 22 as an example.

sudo dnf install perl dos2unix mercurial

After that, the Makefile offers two configure variants. The LuaJIT build is the one the project is named for:

make try-luajit

That target runs all first, then changes into openresty-`./util/ver` and runs ./configure --with-luajit. The plain variant, make try-lua, runs ./configure without the LuaJIT flag and then $(MAKE). There is also make test, which runs prove -I../test-nginx/lib -r t, and make clean, which removes the openresty-* directories. Note that try-luajit and try-lua stop after configure; the Makefile does not show a build step for them, so do not assume they leave you with an installed server. For an actual deployment, the README directs users to the download page and the installation page on openresty.org instead.

Where OpenResty is the wrong choice

The clearest hard boundary is Windows. The README states that the resolv.conf parsing feature is not available on Windows platforms. That is a statement about one directive, not about the whole bundle, so treat it as a signal that platform support is uneven rather than as a complete compatibility matrix. The README does not document which other parts of the bundle differ by platform.

A second limitation is the build path itself. Reproducing the bundle requires perl, dos2unix, and mercurial according to the README, and the default make target fetches and assembles multiple upstream components through ./util/mirror-tarballs. That is a heavier and more network-dependent process than compiling a single upstream tarball, and it is the reason the README separates users from bundle maintainers at all. If your team does not want to own that assembly step, the download page exists precisely so you do not have to.

A third case is architectural rather than technical. OpenResty's value comes from executing logic inside the request path. If your nginx configuration is a reverse proxy in front of an application that already handles the request, adding a Lua layer gives you a second place where behaviour lives. The bundle does not remove that application; it sits in front of it. Teams that want one place to reason about request handling should weigh that before adopting the bundle.

OpenResty compared with plain nginx

The difference in approach is packaging, not the core. Plain nginx gives you the nginx core and whatever third-party modules your distribution or your own build adds. OpenResty gives you the same core plus a curated set of third-party modules plus LuaJIT, assembled and versioned together by the bundle maintainers. The README's stated rationale is that this coordination keeps the modules compatible with one another. With plain nginx, that compatibility work is yours: you pick module versions, you build them against the core you are running, and you resolve conflicts when they appear.

The trade-off runs the other way too. A plain nginx build contains only what you put in it, so the surface you have to track for updates is smaller. The OpenResty bundle ships a larger module set, and the README does not enumerate it in the text provided here. If you need to know exactly what is compiled in, that list has to come from the bundle's own documentation rather than from this README. Choosing OpenResty means accepting a larger, centrally coordinated component set in exchange for not having to coordinate it yourself.

Maintenance, releases, and licensing

The repository is not archived, and its last push was on 2026-09-21. Recent release tags listed for the bundle are v1.27.1.2 and v1.27.1.1, both from 2025-10-08, and v1.25.3.2 from 2024-07-19. The version numbering tracks the nginx core version with bundle-specific suffixes, which is consistent with the README's description of the bundle as the nginx core plus modules. Upgrade cost is therefore not just an nginx upgrade: a new bundle version can move the core and the module set together, and the README does not document a rollback procedure for a bundle upgrade. Plan to test a version change against your configuration rather than assuming the resolver directive and your module set behave identically across tags.

On licensing, the README states that the bundle itself is licensed under the 2-clause BSD license, copyright 2011-2019 Yichun Zhang and OpenResty Inc. It also states that bundled software components are copyrighted by their respective copyright holders, and that the individual module described in the README is licensed under the BSD license. The repository's licence field is reported as NOASSERTION, so the machine-readable metadata does not match the README's plain statement. Because the bundle contains third-party components under their own copyright holders, the licence of the bundle as a whole is not the same question as the licence of each component. This is not legal advice; if your organisation has licence review requirements, the component list is what needs reviewing.

Editorial conclusion

Adopt OpenResty when you need to run logic inside the nginx request path and you are prepared to own a compiled bundle and its module set. Do not adopt it if a plain nginx config with an upstream application already meets your needs, or if you must deploy on Windows, where the bundled resolv.conf resolver feature is not available. Before building, read the download and installation pages on openresty.org and confirm the version you intend to run against the release list; before shipping, verify which third-party modules your configuration actually loads, because the bundle ships more than a default nginx build does.

Frequently asked questions

Official sources

1. Issues
2. openresty/openresty on GitHub
3. Project website
4. README
5. Releases