OpenResty vs NGINX, Caddy and Traefik: Choosing The Edge For Magento

There are a dozen ways to put a web server in front of Magento. I tried most of them and landed on OpenResty — NGINX with Lua superpowers. Here's the honest case for it, and against the alternatives.

Parts 3 to 5 of this series will be published over the coming days. Stay tuned.

Part 2 of 5 in the anti-bot series. New here? Start with Part 1, the overview: *Magento Anti-Bot and Anti-Scraping Guide.*

Pick the web server that sits in front of Magento and you’ve quietly made one of the most consequential decisions in the whole stack. It’s the first thing every request touches and the last thing every response leaves through. I tried a lot of front doors over the years. I landed on OpenResty, and I’ll defend it — but only after being fair to everything it beat.

The one-line version: OpenResty is NGINX with Lua superpowers. Everything good about NGINX as a Magento front door, plus the ability to run real logic at the edge — which, it turns out, is exactly what a modern Magento store needs.

Plain NGINX: right model, not enough rope

Let’s start with the obvious one, because it’s the baseline everyone knows. For a Magento front door you want NGINX, full stop — its event-driven model is the right shape for this workload in a way Apache’s per-request processes simply aren’t. Magento even ships an NGINX config. This isn’t a religious war anymore.

So why not just run stock NGINX? Because the moment you want to do anything genuinely smart at the edge — a proof-of-work challenge for suspicious traffic, custom WAF logic, talking to a security bouncer, shaping requests based on real conditions — plain NGINX hands you static directives and a polite shrug. You can bolt on modules, but you’re recompiling and you’re still not programming. I needed to run logic at the edge, per request, and stock NGINX doesn’t give you the rope. OpenResty is that same NGINX, with Lua wired into every phase of the request. Same foundation, suddenly programmable.

Caddy: lovely, but it can’t stand where I need it

Caddy is genuinely nice — automatic HTTPS, clean config, a pleasure for a lot of jobs. And it keeps coming up because FrankenPHP, the shiny PHP runtime everyone’s excited about, is built on Caddy. I tried that road. The wall I hit is practical: FrankenPHP wants Caddy, and I can’t run Caddy as the front door without throwing away full compatibility with the standard Magento NGINX config — and that compatibility matters far more than it sounds. The Magento NGINX config is a known quantity, battle-tested, and everything from upload handling to static-file rules assumes it. Swapping the whole front door to chase an unproven gain isn’t a trade I’ll make. Caddy’s a great tool standing in the wrong doorway for me.

Traefik: a brilliant router for the wrong problem

Traefik is excellent at what it’s for — dynamic service discovery, routing across a fleet of containers, the cloud-native ingress problem. I actually run it elsewhere for exactly that. But a Magento store’s front door isn’t a routing problem; it’s a single, opinionated, high-performance edge that has to do Magento-specific things and run custom logic on the hot path. Traefik is the wrong altitude — a smart traffic cop when what I need is a tuned, programmable wall. Different job.

APISIX: powerful, and quietly OpenResty anyway

APISIX is a serious API gateway, and here’s the punchline: it’s itself built on top of OpenResty. So when I evaluated it, I was really evaluating “OpenResty with a large API-gateway framework wrapped around it.” For an API-management problem — hundreds of routes, plugins, a control plane — that framework earns its weight. For a Magento front door it’s a lot of machinery I’d have to learn, configure, and keep updated to get to a place I can reach by using the engine underneath it directly. Why take the wrapper when I want the thing it wraps?

Angie and Tengine: the NGINX forks

Then the NGINX forks, because someone always asks. Angie is a newer fork from ex-nginx developers — genuinely promising, some nice features — but it’s younger, the ecosystem is thinner, and I’m not ready to bet a fleet of customer stores on it yet. Maybe later.

Tengine — Alibaba’s NGINX fork — I actually went further with. I was curious enough to try building it from the makefile myself. The result: slow going, and ultimately nowhere sensible to run it that justified the effort over what I already had. It’s clearly capable at Alibaba’s scale, but for my workload it was friction without a payoff I could measure. I gave up and went back to the thing that was already working.

What the Lua superpowers actually buy me

So why did OpenResty win? Because it let me build the exact edge Magento needs instead of approximating it with whatever directives a config language happened to expose. Let me be specific about what runs at that front door, because ‘NGINX with Lua’ is abstract until you see the list.

Brotli compression, so the bytes on the wire are smaller than gzip gets you — free speed on every text response. HTTP/3 and QUIC, so connections set up faster and survive a flaky mobile network without stalling, which matters more for real shoppers on real phones than any synthetic benchmark admits. GeoIP, so I can reason about where traffic is coming from. A CrowdSec bouncer, so known-bad actors are turned away at the door based on a shared, constantly-updated reputation feed rather than a static blocklist I have to maintain by hand. And AppSec rules running inline, inspecting requests for the obvious attack shapes before they ever reach PHP.

And then the one I’m actually proudest of, the one that only exists because Lua let me write real logic in the request path: a proof-of-work challenge for suspicious traffic. When a request looks like a scanner or a scraper rather than a human, the edge can make it do a small computational puzzle before it’s allowed through — cheap and invisible for a real browser, expensive and discouraging at the scale a bot operates. It’s the same idea as the challenge pages you’ve hit on big sites, except it’s mine, running locally, instead of routing every visitor through a third party and paying for it in latency, money, and an extra network hop. I could have taken the easy road and bolted on someone else’s challenge service. It was uglier, slower, and cost money on every request, and my R&D nerves wouldn’t allow it. So I built it. That’s a thing you can only do when your edge is programmable.

Here’s why that last category matters so much for Magento specifically, and it ties back to performance. A scanner swarm doesn’t hammer your cached homepage — it hits the pages caching can’t save you on: search, layered-navigation permutations, the store switcher, add-to-cart and checkout paths. Every one of those sails past Varnish, wakes a PHP-FPM worker, and ties up a process a real customer needed. So shaping that traffic at the edge isn’t a security nicety bolted on after the fact. It’s a performance feature. It reclaims the workers your shoppers are supposed to be using. And it lives at the edge because the edge is the only place to stop it before it costs you anything.

The constraint that quietly disqualified half the field

Through every bit of that — Brotli, HTTP/3, GeoIP, CrowdSec, AppSec, the proof-of-work challenge — OpenResty keeps full compatibility with the standard Magento NGINX config. That sentence sounds boring and it’s the most important one in the post. The Magento NGINX config is a known, battle-tested quantity; the upload rules, the static-file handling, the security paths, the things that route to PHP correctly are all spelled out in it and assumed by every deploy. OpenResty runs that config unchanged and adds the programmable layer around it. I get the power without throwing away the foundation.

That’s the trade nothing else on the list could make. Plain NGINX kept the config but couldn’t program. Caddy could do clever things but couldn’t keep the Magento config and forced a whole runtime change to get there. Traefik was solving a routing problem I didn’t have. APISIX was the long way round to the engine I could just use directly. The forks were either too young to bet a fleet on or not worth the effort once I’d actually tried them. OpenResty was the only one that gave me programmability and the known-good Magento foundation at the same time — and once you frame the requirement that way, it almost picks itself.

The front-door decision, in one table

Boring foundation, power where it counts

None of this is exotic for its own sake — and if you’ve read anything else I’ve written you know that’s the through-line of everything I build. Boring, known-good foundation; just enough power applied exactly where the workload actually demands it, and nowhere it doesn’t. OpenResty is NGINX you can reason with and program, and a Magento front door — the first thing every request touches, the place performance and security are both won or lost — is precisely the spot where that reasoning pays for itself a hundred times over.

If you want the deeper dive on why the edge matters so much for raw performance — the scanner-bot problem especially — I went into it at length in my Magento performance post. This post was the front-door decision. The rest of this series is what the front door actually does with all that Lua: how we fingerprint connections (including the part where I patched OpenResty from source to read HTTP/2), how we score every request, and the proof-of-work challenge I ended up building three times, because apparently I enjoy pain.

Next up, Part 3: How to Spot a Fake Chrome (coming soon).

The anti-bot series: *Part 1: Overview · Part 2: OpenResty vs NGINX, Caddy and Traefik · Part 3: How to Spot a Fake Chrome (coming soon) · Part 4: How to Build a Bot Score (coming soon) · Part 5: Self-Hosted Proof of Work with ALTCHA (coming soon).*

The edge is where a lot of Magento performance and security is won or lost. StoreFrame runs a tuned, programmable OpenResty front door on every store — yours included.
See how StoreFrame works