JFrog Artifactory Supports LuaRocks Hosting for NGINX, OpenResty and Kong

If your NGINX/OpenResty servers or Kong gateways pull Lua modules straight from public luarocks.org, one upstream outage can stall every build and deploy that depends on a “rock”. With LuaRocks support in JFrog Artifactory, you host and proxy those modules from a private LuaRocks registry you control, using the native experience you expect, not a bolted-on workaround. This post covers the benefits of using Artifactory as your LuaRocks registry, why it matters for OpenResty and Kong specifically, and how to point the luarocks client at Artifactory in just a few minutes.

Pulling rocks straight from luarocks.org

LuaRocks is the package manager for Lua, playing the same role as npm does for JavaScript or pip for Python. A single package is a rock, and its manifest is a rockspec. If you run Lua in production, you are almost certainly pulling rocks with the luarocks command.

Most Lua shops install rocks directly from luarocks.org at build time. That works, until it doesn’t. This can be due to a number of circumstances including:

• When luarocks.org is slow or unreachable, your builds and deploys wait along with it.
• Every machine re-downloads the same rocks, with no shared cache, so each pull leaves through your NAT gateway as separate outbound traffic instead of one controlled path.
• Your own internal rocks and Kong plugins are stored wherever someone last put them, with no centralized repository to access them.

For just a handful of scripts, that may be workable. For a fleet of NGINX/OpenResty edge servers or a production Kong cluster, depending on a public registry you do not control is a risk to availability.

A private LuaRocks registry in JFrog Artifactory

JFrog Artifactory now supports LuaRocks as a native repository type, with the same three-repo model approach that thousands of JFrog customers already use for Maven, npm, NuGet and other leading open source repositories:

Division into local, remote, and virtual repositories, also enables assigning different access rules for each one, such as having stricter permissions on your own rocks as opposed to those that are cached publicly.

The remote repository fetches a public rock on first request and serves it from the cache on every request thereafter. The virtual repository puts the private and publicly cached rocks behind a single address, so the luarocks client only needs to communicate with a single endpoint.

Repeat downloads come from your own cache instead of luarocks.org, and every rock your organization uses, public or private, sits behind one address. The same local, remote, and virtual repository model you already run for Maven or npm, now works for Lua as well.

There are two workloads that particularly benefit from JFrog’s private LuaRocks registry: OpenResty modules and Kong plugins running at the edge.

OpenResty and NGINX: serving the lua-resty modules yourself

OpenResty extends NGINX with Lua so you can run logic at the web-server layer including: Routing, rate limiting, authorization, and request shaping at the edge. The building blocks are the lua-resty-* family of rocks, like lua-resty-http for outbound calls, lua-resty-redis for Redis access, and lua-resty-openidc for OIDC and OAuth at the edge.

Most teams install those rocks from the public registry on each server. By pointing luarocks at a JFrog Artifactory virtual repository instead, the same lua-resty-* rocks resolve from your cache, resulting in faster installs across your entire edge fleet. You can also host internal forks of a lua-resty module in the local repo and pin every edge node to the exact version you tested, to ensure that a configuration  rollout installs the same rock in every instance..

Kong: shipping custom plugins as private rocks

Kong Gateway is built on OpenResty, and its custom plugins are written in Lua. Kong packages and installs those plugins as LuaRocks rocks, where you can build a rockspec, produce a .rock file, and run luarocks install to put the plugin on each node. Kong can install from a remote rock server, and a JFrog Artifactory LuaRocks repository is exactly that.

So an Artifactory local repo becomes the private plugin registry for your Kong fleet. Your CI job builds the .rock, publishes it to the local repo, and every Kong node installs the same versioned plugin from one place, instead of files being copied manually each time. Promoting a plugin from staging to production is a version bump instead of manually copying files,  thereby improving the integrity and traceability of your deployments.

Kong also supports OCI-packaged plugins, and Artifactory covers that path too, so the story holds no matter which one a Kong shop uses.

Why this matters now

Lua stopped being a scripting afterthought once OpenResty and Kong became part of production traffic. Today, it runs in the request path of NGINX/OpenResty edge servers and Kong gateways, two of the most widely deployed components of API infrastructure. When code sits that close to production traffic, the registry that feeds it should not be a public site you cannot control.

Maven, npm, NuGet, Docker, and other leading package types already run through a private registry at most shops. Lua usually doesn’t. Native LuaRocks support in JFrog Artifactory helps close that gap, so your gateway and edge tier get the same hosting and availability as the rest of your software, with a single client pointed at a single endpoint.

For information on how to get started, please see the LuaRocks repository documentation.

A LuaRocks install resolving a rock from a JFrog Artifactory virtual repository

One registry for all your Lua Packages

NGINX/OpenResty modules and Kong plugins are Lua, and Lua has a package manager. With LuaRocks support in JFrog Artifactory, that package manager now points at infrastructure you control. Private rocks are stored  in a local repo, while the public ecosystem is cached through a remote repository with a single URL for both. Your edge servers and gateways stop borrowing someone else’s uptime and your Lua rocks become part of your single, governed software supply chain.

Ready to host your own rocks? Start for free, and create your own LuaRocks repository.