DEV Community: Laurentius Judhianto

How to Build a Bot Score: 11 Signals That Separate Scrapers from Shoppers

Laurentius Judhianto — Fri, 02 Oct 2026 14:02:06 +0000

More than ten detectors score every request before anything is decided. Here is the scoreboard, what each signal is bad at, and the customers we annoyed on the way.

Part 5 of this series will be published in the coming days. Stay tuned.

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

Picture a nightclub bouncer with a clipboard. Not the one who refuses you for wearing trainers. The good one, who notices that you arrived in a taxi that does not exist, claim to be on the list under a name that belongs to someone else, and have been walking in and out of the door forty times without ever buying a drink.

None of those alone gets you thrown out. All of them together, and you are going home.

That is the job of the scoring layer at the edge of every Magento store we run. Every request gets looked at by more than ten independent detectors, each one adds to a score, and only then does anything get decided. This post opens up the scoreboard: what the signals are, what each one is good and bad at, and the embarrassing list of real customers we accidentally annoyed along the way.

First match wins was the mistake

The first version, was a list of rules. Fourteen steps, checked in order, and the first one that matched decided what happened. Simple, fast, and completely useless when something went wrong.

If a request was blocked by rule three, we never learned what rules four to fourteen thought. When a real customer got refused, the log said one reason. Usually the wrong one.

Later on we rebuilt it into four phases: a few quick exits, then every detector runs and none of them stops early, then the scores are added up into a verdict, then we log and act. Every signal is recorded on every request, whether it mattered or not. That single change is why every number in this series exists.

The scoreboard

Here are the signals. I have left out the weights and thresholds on purpose; the categories are the interesting part anyway, and the right-hand column is the honest part.

What feeds the score

	What it catches	How it gets fooled
User agent claims	Empty user agents, self-declared libraries, browser versions that retired years ago	Copy a real browser's user agent. Takes ten seconds
Header consistency	Clients that claim to be a browser but forget what browsers always send	Copy the full header set too. Takes a minute
TLS fingerprint (JA4)	Scripting libraries and frameworks wearing a browser name tag	Browser-impersonating TLS libraries, or a real browser
HTTP/2 fingerprint	The stacks that faked the TLS hello but not the conversation after it	Faking the full HTTP/2 stack, or a real browser
Crawler verification	Impostors calling themselves Googlebot or Bingbot	Not really: you cannot fake Google's DNS
Behaviour	Visitors that read page after page without loading a single image	Automated real browsers load assets like anyone else
Client checks during the challenge	Automation flags and inconsistencies a real browser does not have	Stealth plugins, which is why this is never decisive
Reputation	Addresses the community has already seen misbehaving	Fresh residential addresses have a clean record
Request pressure	Visitors hammering the store far faster than anyone shops	Spread the load over thousands of addresses
Cold deep links	First visits that land straight on a filtered or parameterised URL	Easily, on its own. Which is why it is one line on the scoreboard, not a rule
Firewall hits	Requests that carry attack payloads	Nothing subtle: this one ends the conversation

Read the right-hand column. Almost everything can be fooled on its own. That is the whole argument for scoring: a bot has to fool all of them, at the same time, while still looking like the same visitor. Each extra column it has to beat costs it money, time or both.

Four ways a request can end

**Pass. **The page is served, nothing happens. This is where nearly every shopper lives.

**Challenge. **The real page is served, and a small proof-of-work puzzle solves in the background. The shopper does not notice. A script that cannot run JavaScript never gets its pass.

**Ban. **A short interstitial page that solves itself, or asks for a click on the harder cases.

**Block. **A plain refusal. Reserved for the certain cases.

Across multiple production stores over a given period, 82% of requests passed untouched, 3.4% were challenged invisibly, 8.2% hit the interstitial and 1.5% were blocked outright. Looking only at page requests, 19% came from a clean browser, 31% were verified search engines, and the rest was automated or suspicious. Your analytics will never tell you that, because most of those visitors never run your analytics script.

Googlebot, or "Googlebot"

Crawler verification is the one signal that is close to unfakeable, and it produced my favourite number of the whole series.

For anything claiming to be a search crawler, we look up the hostname behind the connecting address, check that it belongs to the search engine, then look that hostname up again and confirm it points back to the same address. It is the method Google itself recommends. The result is cached, so it costs almost nothing.

Over the same period, 210 of the 408 addresses that called themselves Googlebot were fake. Bing, by comparison, had 3 impostors out of 289. Apparently nobody dresses up as Bing. The fakes were refused 97% of the time; the real Google sent 98% of the Googlebot traffic and was never challenged once, because a store that blocks Google has solved the bot problem in the least useful way possible.

The hall of shame

Every signal in that table has, at some point, fired on someone it should not have. Here is the list, because pretending otherwise would be the least credible thing in this post.

**Our own dashboard. **Banned by our own edge, the same week the scoring went live. Clean work.

**Home internet on IPv6. **Some residential providers give their customers reverse-DNS names that looked suspicious to the crawler check. Real people, flagged for their ISP's naming taste.

**Facebook link previews. **Somebody shares a product, Facebook fetches it, we refuse Facebook. Not ideal for a shop.

**Google Ads and newsletter clicks. **They arrive with long tracking parameters, which looked a lot like a bot guessing URLs. We relaxed that signal. Scrapers noticed and started dressing up as ad clicks. We tightened it again, more carefully.

**Our own colleagues. **Team members on certain ISP or VPN, where a lot of home traffic looks like data centre traffic, got throttled. We changed how much that signal is allowed to count.

Every one of these was caught because every signal is logged, and fixed by adjusting one weight rather than tearing out a layer. That is the other benefit of scoring: mistakes are tunable, not fatal.

Why not just block by address?

Because addresses have stopped meaning anything. On a day in September, one store saw 32,462 refused requests in one hour from 31,201 different addresses. Roughly one request each. A per-address rule sees thirty-one thousand polite strangers.

Many of those addresses are residential proxies: real home and mobile connections rented out to scrapers. Blocking them outright also blocks the shopper who happens to share that connection tomorrow. So the score has to judge the visit, not the address, and the next part of this series, about proof of work, is how we make those visits expensive instead of trying to blacklist the planet.

Finally, measuring it and constantly update algorithm

An anti-bot layer you cannot see is a rumour. Every decision the edge makes lands in a central log store, off the store itself, with every signal attached.

None of it is perfect, and none of it has to be, I don't think it ever will. The score does not need to be right about every visitor. It needs to be right about enough of them, cheaply, while the other layers catch what it misses. Finding the right balance between acessibility and security.

Numbers in this post come from the edge logs of selected production stores we operate, over a given period — about 8.5 million requests. Store names are left out on purpose.

Next up, Part 5: Self-Hosted Proof of Work with ALTCHA (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 · Part 4: How to Build a Bot Score · Part 5: Self-Hosted Proof of Work with ALTCHA (coming soon).*

StoreFrame scores every request at an OpenResty edge in front of every Magento store it runs: fingerprints, crawler verification, behaviour and reputation, with every decision logged centrally.
See how StoreFrame protects Magento stores

How to Spot a Fake Chrome: JA4 and HTTP/2 Fingerprinting Explained

Laurentius Judhianto — Mon, 28 Sep 2026 09:53:42 +0000

Every bot says it is Chrome. The handshake says otherwise. How we read JA4 and HTTP/2 fingerprints at the edge, why we needed both, and where they fail.

Parts 4 and 5 of this series will be published over the coming days. Stay tuned.

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

Every bot on the internet is Chrome (webkit, sort-of). Just ask it. Chrome on Windows, the latest version, with all the right headers, freshly copied from a real browser by someone who read a blog post much like this one.

The user agent is a name tag. Anyone can write anything on a name tag (a curl posted with a handwritten UA can bypass Cloudflare, maybe the free one, yet it did). What is much harder to fake is the way a client actually talks: how it negotiates encryption, and how it opens an HTTP/2 connection. Those habits live deep inside the network library, and most scraper authors never touch them.

This post is about reading those habits on every request at the edge of a Magento store: what JA4 and HTTP/2 fingerprints are, why we needed both, the afternoon I spent patching OpenResty from source, and the day fingerprints let us down.

Great if you haven't heard of it!

JA4: the handshake as handwriting

Before any page is requested, the client says hello to the server and lists what it supports: which versions of TLS, which ciphers, which extensions, which protocols it would like to speak next. Chrome says hello one way. Firefox another. Python's requests library, Go's HTTP client and curl each have their own accent.

JA4 is an open standard from FoxIO, launched in 2023, that turns that hello into a short fingerprint. It replaced the older JA3 for a very practical reason, as Cloudflare explains: in 2023 Chrome started shuffling the order of its extensions on every connection, which made JA3 fingerprints change constantly. JA4 sorts them first, so the shuffle stops mattering.

The trick is not identifying the browser. We do not care whether you are on Chrome or Firefox. We care whether the handshake belongs to a browser at all, when the name tag says it does.

HTTP/2: the layer they forget

Here is the problem with TLS fingerprints on their own: there are libraries whose whole job is to fake a browser's hello, byte for byte. Good ones. Scrapers use them.

But after the hello, if the connection speaks HTTP/2, the client sends its opening settings: window sizes, limits, and the order in which it lists certain headers. Every browser engine has its own habits here too, and they come from the HTTP stack, not the TLS library. Faking the handshake does not fake these. You have to fake the whole conversation, consistently.

Stock NGINX does not expose any of this. Neither does OpenResty. So we took the HTTP/2 part of an open-source fingerprinting patch (nginx-ssl-fingerprint), stripped out everything else, and compiled it into the NGINX core inside OpenResty. That meant giving up prebuilt images and building our own, from source, in stages.

The first version worked perfectly, in the sense that it compiled, started, and returned an empty fingerprint for every single request. A missing flag. Two days later it was reading real values.

OpenResty: the edge

Now the evidence. Across multiple production stores over a given period, 174,920 requests that claimed to be a browser had the connection of something else: 3.4% of all browser-claiming traffic, from 18,325 addresses.

The TLS fingerprint caught most of them: about 129,000 had handshake traits no current browser sends, and another 41,000 matched signatures of known scraping frameworks. The HTTP/2 fingerprint caught another 4,136 that the handshake missed: Python, curl and Java stacks, all wearing a Chrome name tag.

And the number that justifies building both: only 86 requests were caught by both fingerprints at once. They overlap almost nowhere. Each catches what the other misses. Remove either one and a whole category walks in.

Where fingerprints fail

I promised trade-offs, so here they are. Fingerprints catch fakes. They do not catch the real thing.

**A real browser is a real browser. **In one period, a swarm hit one of our stores running genuine Chrome, driven by automation. Its fingerprint was identical to that of 465 real customers' addresses on the same store. At the time we had a wall that armed itself on fingerprints when the store was under load. It did exactly what it was told: it turned away real shoppers, and it broke checkout. We removed it shortly for good. Keying on identity is a dead end when the identity is shared with your customers.

**The network can rewrite your handshake. **A few months back, one of our own team was on an a certain ISP and got refused by our own edge. The carrier was intercepting TLS, so a perfectly normal phone arrived with a handshake that did not look like a phone. Corporate proxies do the same thing. Your customers do not choose their networks.

That is exactly Cloudflare's point: fingerprints can be easily spoofed, they change frequently, and traffic keeps evolving. So on the pages shoppers browse, a fingerprint mismatch is never a verdict on its own. It is evidence. It feeds the score, along with everything else, and the score decides. In our data, some mismatched requests still pass, because nothing else about them looks wrong.

The one place a mismatch is a verdict

Stores also have machine-facing channels, where payment providers, marketplaces and stock systems talk to Magento. Honest software on those channels introduces itself honestly. It has no reason to pretend to be Chrome.

So when a client on a machine channel claims to be a browser and its connection says otherwise, there is only one explanation left (malicious). N a price scraper went after a store's product catalogue through its machine channel, dressed as Chrome. Since then that combination is refused outright.

Fingerprints are not a wall. They are one of the layers that makes lying expensive. Fake ones are definitely goes to the bin with difficult proof of work. The next part is about how all the layers add up to a decision.

Numbers in this post come from the edge logs of selected production stores we operate, over a given period — about 8.5 million requests. Store names are left out on purpose.

Next up, Part 4: How to Build a Bot Score (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 · Part 4: How to Build a Bot Score (coming soon) · Part 5: Self-Hosted Proof of Work with ALTCHA (coming soon).*

StoreFrame reads the TLS and HTTP/2 fingerprint of every request at an OpenResty edge in front of every Magento store it runs, alongside scoring, proof of work and a firewall. No third party in the path.

See how StoreFrame protects Magento stores

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

Laurentius Judhianto — Thu, 24 Sep 2026 09:45:42 +0000

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

	OpenResty (what I run)	The alternatives
Run logic at the edge	Yes — Lua in every request phase	Plain NGINX: no. Caddy: limited. Traefik: routing only
Keep stock Magento NGINX config	Yes, unchanged	Caddy: no (runtime change). Forks: mostly, but unproven
Own proof-of-work / WAF logic	Yes, self-hosted, no extra hop	Usually means a third-party service + latency + cost
Right job for a Magento front door	Yes	Traefik/APISIX: built for routing / API gateways
Maturity to bet a fleet on	Yes — years in production	Angie: young. Tengine: friction, no payoff for me

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

Magento Anti-Bot and Anti-Scraping: A Layered Defence Guide for Self-Hosted Stores

Laurentius Judhianto — Wed, 23 Sep 2026 13:15:16 +0000

Half of a Magento store's traffic are bots, and today's scrapers solve puzzles and rent home internet. Here is the layered strategy we run, with real numbers.

Every Magento store I run has more visitors that are bots than human. I used to say that as a joke. Then I counted.

Across multiple production stores over a given period, only 19% of page requests came from a clean, ordinary browser. Another 31% were verified search engines, which we want. The remaining half was everything else: price scrapers, stock checkers, SEO tools, AI crawlers hoovering up product copy, credential stuffers, and a steady drizzle of vulnerability scanners.

Most of it is not an attack. All of it costs money. A bot walking your layered navigation burns the same PHP and database time as a shopper, and the shopper is the only one who ever pays you back.

On a managed platform with a giant CDN in front, somebody else fights this for you. Self-hosted, congratulations: you are the CDN. That is why I think anti-bot is the hardest part of running Magento yourself. Harder than caching. Harder than upgrades. And constantly eating server resources.

This post is the overview of how we handle it on every store we operate. Each layer gets a short section, and four follow-up posts go deeper. I will explain how each piece works. I will not publish the numbers, weights or exceptions, for reasons that become obvious by the end.

Scrapers in 2026 are not your cousin's curl script

Let me set expectations, because the internet still thinks a bot is a Python script with a funny user agent. Some are. The ones that matter are not.

**They solve proof of work. **One swarm that hit us solved our challenge every single time it was asked: 2,490 challenges, 2,490 solutions. Politely. Instantly.

**They drive real browsers. **Detecting headless Chrome was a fun hobby in 2020. In February 2026 we added headless detection to our challenge page and removed it the same evening, because stealth plugins walked straight past every check. A real browser, driven by automation, is still a real browser.

**They rent your customers' internet. **Residential proxy networks route scraper traffic through real home and mobile connections. A scraper on one of those looks exactly like a shopper on a VPN, or on a mobile carrier doing something creative with its traffic. Block the address and you block the buyer.

**They spread thin. **One hour on a day in September, one store: 32,462 requests from 31,201 different addresses. That is roughly one visit per address, then gone. Any rule that counts requests per address sees 31,201 perfectly polite visitors.

**They lie about who they are. **Most of them claim to be Chrome. Many claim to be Googlebot. The claiming is cheap; making everything else agree with the claim is not, which is where most of our catching happens.

**And fingerprints have flaws too. **In August, a swarm ran genuine Chrome. Its fingerprint was shared with 465 addresses of real customers on the same store. We had a wall that armed itself on fingerprints when a store was under load. That day it turned away real shoppers and broke checkout. We took it down for good. Lesson paid for in full.

There is no one thing

If you have read ZDNet's piece on Anubis, the open-source bot blocker that makes every visitor solve a proof-of-work puzzle, you know the idea is good. It is the same family of idea we use. Its own README calls it a bit of a nuclear response, and it is honest about why.

Then, in August 2025, Codeberg reported that AI crawlers had learned to solve the Anubis challenges. Not because Anubis is bad: any single mechanism, once popular, gets optimised against.

Cloudflare says the same thing about fingerprints in its JA4 signals write-up: fingerprints can be easily spoofed, they change frequently, and traffic keeps evolving. Their answer is to combine them with other signals. So is ours.

So the strategy is not a wall. It is a lot of small, cheap questions, each of which a bot can pass, and very few bots can pass all of them at once while still looking like the same visitor.

The edge: OpenResty instead of plain NGINX

Every store sits behind OpenResty: NGINX with a Lua runtime inside, so every stage of a request, from the encryption handshake to the log line, can run our own logic before a single line of PHP wakes up.

Plain NGINX can match paths and count requests. It cannot inspect a connection, keep a score, or talk to a challenge service. Part 1 covers why OpenResty and not Caddy, Traefik, APISIX or the forks: OpenResty vs NGINX, Caddy and Traefik.

Detect first, decide later

The most important design rule is boring: no single signal is allowed to block anyone.

Every request runs through every detector, and each one only adds to a score. Only when all of them are done does the edge look at the total. Low score, the visitor passes untouched. Middling, a challenge runs in the background. High, they are refused.

In our week of data, 82% of requests passed untouched, 3.4% got an invisible challenge, and 9.7% were stopped. Part 3 opens up the scoreboard: How to Build a Bot Score.

JA4 and HTTP/2: fingerprinting the connection

Every bot claims to be Chrome, and many copy Chrome's headers perfectly. What they rarely copy is how Chrome connects. The encryption handshake is as distinctive as handwriting, and JA4 turns it into a short fingerprint. HTTP/2 adds a second one: the settings a client announces when it opens the connection, baked deep into its network stack. Stock NGINX exposes neither, so we patched OpenResty from source to read them.

We do not care which browser you use. We care whether your connection matches the browser you claim to be. In our week of data, 174,920 requests claiming to be a browser had the connection of something else. Only 86 of them were caught by both fingerprints. Each caught what the other missed. That is layering in one number.

Part 2 goes deep on this, including the bugs: How to Spot a Fake Chrome.

Reverse DNS against the fake Googlebot

The oldest trick in the book: call yourself Googlebot. Stores are terrified of blocking Google, so plenty of setups wave that name straight through.

Google publishes how to verify its crawler: look up the hostname behind the address, check it is Google's, then confirm that hostname points back to the same address. We do that for anything claiming to be a search crawler.

The result made me laugh out loud: 210 of the 408 addresses claiming to be Googlebot were fake. The real Googlebot is never challenged, because we want to be indexed. The impostors were blocked 97% of the time.

Behaviour and reputation

A real browser viewing a product page also downloads its images. A scraper that only wants the HTML usually does not. Page after page with no pictures feeds the score quietly.

CrowdSec adds memory: a community blocklist of about 22,000 to 25,000 addresses per store, dropped at the firewall before they reach the edge. Addresses that merely behaved oddly get a score bump instead of a ban, because a shared office network should not be punished for one noisy laptop.

The Turnstile strategy, without the Cloudflare

Cloudflare Turnstile changed how people think about captchas: most visitors should never see a puzzle. The browser proves itself quietly in the background, and only the doubtful ones see anything.

We loved the strategy and did not want the dependency: third-party JavaScript on every page, a vendor in the checkout path, visitor data leaving the store. So we built the same pattern ourselves, self-hosted, and it took three attempts to get it right.

There is a boring reason too, and it might be the best one: time. Turnstile is set up per site, by a person: an account, keys, a widget wired into the store, domains to register. Ours ships with the store. It is installed automatically when a store is first provisioned, so every store has the same protection from day one, and nobody has to remember to go and set up a captcha. Part 4 is the story: Self-Hosted Proof of Work with ALTCHA.

Proof of work and ALTCHA

What the browser solves is a proof-of-work puzzle: search for a number that makes a deliberately slow hash come out right, which the server checks in one go. For one shopper that is a moment of CPU they never notice. For a scraper opening thousands of fresh sessions an hour, it is a compute bill, every session, forever. Proof of work does not prove you are human. It makes being a bot at scale expensive.

The engine is ALTCHA, an open-source, self-hosted, proof-of-work captcha running inside the edge. No image grids, no traffic lights, no data leaving the store. We also use it inside Magento, replacing reCAPTCHA on the storefront forms.

Does it work? Of the 404,149 visitors who were shown the full challenge page in our week, 85.6% never solved it. Some of the ones who did were bots too, which is fine: they paid for the privilege, and the other layers were still watching.

So when do we actually show the challenge?

Putting every request through proof of work is the Anubis approach, and it is a bad experience for a shop. Shoppers are impatient, phones are slow, and every half second on a product page is conversion you will never see. So we are picky about it:

**First visit from a browser: **an invisible check in the background, on the real page. The shopper reads the product title; the browser does the maths.

**A doubtful score: **the same invisible check, with the page still served.

**A high score: **a short interstitial that solves itself. A script that cannot run JavaScript is stuck at the door.

**A cold hit on an expensive page: **catalogue search, deeply filtered categories. These cost the database real work, so a visitor arriving there with no history on the store proves itself before the query runs. That one-hour swarm of 31,201 addresses? Almost all of it was aimed at site search, and it hit this gate.

**A store under pressure: **the puzzle gets harder for everyone who has not already earned trust. The cost follows the abuse, not the address, so rotating addresses does not help.

Verified search engines never see a challenge. A returning shopper with a valid pass does not see it again for a while. And software that talks to the store through its own machine channels, like payment providers and stock systems, is judged by different rules, because it cannot solve a browser puzzle and should not have to. We wrote about how that played out during a real zero-day in We Survived StyleSmuggler.

Where the bots actually go

Of everything we stopped, 46% was aimed at site search, 21% at layered-navigation filters, 19% at product, category and content pages, and 9% was exploit probes. Checkout and login together: under half a percent.

Read that again. The bots are not after your checkout (some does for skimming). They are after your catalogue, and specifically the pages that are most expensive for you to render. Anti-bot on a store is as much a performance feature as a security one.

Behind the edge

Anti-bot is the front line, not the whole defence. Behind it sit a web application firewall, a Varnish cache and a hardened, watched host. Every decision the edge makes is logged centrally, off the store, which is how every number in this post exists.

What I deliberately left out

There is not a single threshold, weight, cookie lifetime or exception list in this series. That is not modesty. Every number I publish is a number someone can tune against, and a list of what we skip is a list of where to aim.

I am also not going to pretend it is perfect. A patient human in a real browser on a real home connection is, correctly, indistinguishable from a customer. The goal was never to stop everyone. It was to make automated abuse slow, expensive and noisy, while a real shopper notices nothing at all.

Many small questions instead of one big wall. Detect first, decide later. Make bots pay in CPU instead of making people pay in patience.

Numbers in this post come from the edge logs of selected production stores we operate, over a given period — about 8.5 million requests. Store names are left out on purpose.

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

StoreFrame runs Magento on your own cloud with this edge in front of every store: an OpenResty anti-bot layer, self-hosted proof-of-work challenges, a firewall, hardened containers and central logs. It is not an add-on; it is the platform.
See how StoreFrame protects Magento stores

Agentic Operations, Not Agentic Commerce. What Do You Mean?

Laurentius Judhianto — Mon, 21 Sep 2026 20:07:24 +0000

Everyone talks about agentic commerce — agents that shop and check out for you. Fine idea. Not my idea. I’m focusing the half nobody looking at: the agent that helps the operators, not the one that buys.

So what’s your goal, Laurentius?

I get asked a version of this a lot: what are you actually doing here? There’s nothing genuinely new — nothing other developers couldn’t replicate. Where are you going with it? Fair question.

Here’s the brutally honest answer.

My goal with StoreFrame was never to start an agency or another hosting company. I’m lazy, and I get bored repeating the same work over and over. Magento eats too much time, and I wanted to automate that time away — especially now that AI makes it possible.

So the point is to automate everything I already know how to do, so I’m free to go learn the thing I don’t. That’s it. That’s the whole motive.

StoreFrame begins as a library, not a hosting plan

Here’s how I actually think about what I’ve built. I’m a bit like an AI with a small context window — learning languages is hard for me, even down to remembering syntax. So instead of keeping a thousand-page Notion of best practices I’ll never re-read, I poured all of it into a system. Every tuning lesson, every deploy recipe, every guardrail, every “don’t do the thing that broke production last year.” StoreFrame is that library of operational knowledge, turned into something that runs.

That library is what scales me. It’s also the showcase — proof of what I can do, running live, instead of a slide deck claiming it. And the part that makes it agentic is that an AI can now read that library and act on it, on a real store, with the guardrails baked in. The knowledge isn’t advice anymore. It’s an operator.

Why operations, not commerce

Agentic commerce points the agent at the shopper — go find this, compare those, fill the cart, check out. Agentic operations points it the other way entirely, at the shopkeeper. At the unglamorous, endless, invisible work of keeping a Magento store fast, secure, deployed, monitored, patched, and changed without anything breaking. The work nobody sees and everybody needs.

And here’s why I think that’s the more interesting half. That operational work has always required a specialist — a developer, an agency, someone who knows where the bodies are buried in a Magento install. Specialists don’t scale; there are only so many hours in their day and only so many of them to hire. So merchants get stuck on a bad trade: either they under-buy attention and the store quietly rots, or they over-buy it and pay agency rates for changes that take ten seconds and a week of back-and-forth.

Agentic operations is my answer to that trade. If the specialist’s knowledge lives in a system instead of in a head, the merchant stops buying hours and starts buying the knowledge itself — available at three in the morning, on every store at once, at the same standard every time. The specialist doesn’t disappear. They stop being the bottleneck.

Laying down the foundation for AI

AI is going to write the code, Magento included — that part is inevitable. What it still needs is context. An AI is only as good as the information you can put in front of it, and the best way to collect, shape and serve that information is to own the layer everything passes through. The infrastructure.

That’s why StoreFrame isn’t focused on Magento itself, but on everything around it, starting from the fundamentals. When you control the infrastructure, you control the flow of information: what comes in, what goes out, how it’s processed, where it came from and what happens to it next. That gives an AI a large and honest body of data to answer almost anything you ask — from product information down to raw web traffic.

Owning that layer also buys room traditional hosting doesn’t leave you: custom MCPs, custom containers, custom data processing. Performance is tunable from every angle too — anti-bot handling, NGINX configuration, PHP profiling. I leave no stone unturned, because every stone is one more thing the AI gets to see.

Business is a system

That’s the bet, stated plainly. Not an agent that replaces the customer’s search bar — an agent that works for the operator, and knows where every piece of data came from. Give it enough context and the guessing drops away; what’s left is a system that gets measurably better each time it runs.

Because that is what a business is, isn’t it? A system, optimised over and over. I’m just handing the optimising to an AI agent that never gets bored.

StoreFrame is Magento infrastructure built for AI. It runs every layer of the store — traffic, containers, deploys, logs — so an AI agent can see exactly what is happening and take over the routine work operators do by hand. On your own cloud.
See how StoreFrame works

How I Made a Luma Theme Faster Than Hyva on Hypernode — Without Spending Days

Laurentius Judhianto — Wed, 10 Jun 2026 14:33:47 +0000

How I Made a Luma Theme Faster Than Hyva on Hypernode — Without Spending Days

Hyva on Hypernode is the premium combo for a fast Magento store. But what if your existing Luma theme could beat it — without a rewrite or days of work?

On paper it shouldn’t have been close. In one corner, Hyva on Hypernode — the premium combo everyone reaches for when a Magento store has to be fast. In the other, a five-year-old Luma theme with a dated design and images not even saved as WebP, running on a plain Hetzner box at roughly half the monthly cost. The old store answered faster.

A disclaimer before anything: this isn’t a knock on Hyva or Hypernode or the agency — all are genuinely excellent, and I’ll show you exactly where they win. I also don’t have access to the Hyva-on-Hypernode box, so I can’t run hardcore server-side metrics on it. This is Lighthouse plus an honest, perceived-speed comparison on two real, live stores — read it as “here’s what I saw,” not a lab verdict.

Credit where it’s due. Hyva is the most solid choice in open-source Magento 2 if you want real performance and a nice templating frontend — and the clever part is what it leaves out.

It pairs Tailwind with Alpine.js (I first met Alpine over in the Laravel world) and sheds the pile of old library bloat Magento carried for years. Tailwind especially: you build a frontend without the CSS quietly ballooning.

Small personal aside. I’ve believed in this approach for a long time. Around 10 years ago, while I was still an employee, my habit of leaning on utility classes right in the markup earned me some side-eye — this was the Bootstrap-4-hung-the-moon era, before Tailwind existed.

Now utility-first is the industry standard, all AI generated is all Tailwind. Sigh.... I guess I was just early.

Hyva is also a relief after the PWA detour. Magento 2’s frontend is hard enough on its own; PWA Studio made it dramatically harder — a completely separate stack with its own build and deploy procedure, foreign to anyone (inc. me) whose muscle memory is PHP. A lot of teams bounced off it. Hyva went the other way: modern interactivity without abandoning the .phtml and XML we already knew, and that’s a big part of why it won.

Split frontend and backend might still have its comeback — as AI-agent aces Javascript like Magnus Carlsen plays blindfolded Chess against 8 Grand masters, and something like Claude can design and build a frontend end to end in seconds, a decoupled stack could finally be worth the overhead. But that’s a story for another day.

Anyway — enough about Hyva. We all know it’s ~~good~~ great. So why wouldn’t a merchant just go straight for it? Cost, mostly — and not mine, theirs. A Hyva license (recently made free, hooray) plus a premium modules from Amasty and host like Hypernode is a real monthly bill, and plenty of merchants simply don’t want to take it on.

And it isn’t only hosting and licensing: moving to Hyva means every module you depend on has to be adapted to its frontend — Hyva-compatible builds or porting work — more cost and more time before you’ve sold a single extra product.

Setting the ground

So I set up an honest comparison, and laid out the rules first.

The deal: a comparable Hypernode plan runs €637/month. The StoreFrame side is €340 — €250 for the management hub plus €90 for the Hetzner bare metal. Here's the hardware, side by side:

	StoreFrame (Luma Based)	Hypernode (Hyva)
Server	Hetzner EX101 — bare metal	Jackal S — dedicated tier
CPU	Intel i9-13900 · 24 cores / 32 threads · up to 5.6 GHz	AMD Ryzen · 12 cores
Memory	64 GB DDR5 ECC · 4400 MT/s	64 GB
Storage	2× 1.92 TB Gen4 NVMe	—
Cost / month	€340/mo (€250 hub + €90 server)	€637/mo

The StoreFrame stack: OpenResty with Brotli, HTTP/3 and QUIC, three Redis instances, MariaDB, PHP-FPM, OpenSearch, our licensed Luma-based theme (which include Swissup module for page speed), and Varnish, obviously. There’s no magic sauce — just properly tuned Ubuntu and Docker containers working in sync.

And the honest handicaps, all on my side: the Luma store runs an older Magento 2.4.8 on PHP 8.4 — a basic theme - plain StoreFrame theme design I've made 5 years ago (back then the focus was not the design, just to get a proper single Magento2 webshop merge from multiple Magento1), so the design itself is dated. The images aren’t even optimized to WebP. The Hyva-on-Hypernode store is newer across the board, fresh - clean and sharp.

A level playing field

One rule mattered more than the rest: keep it a level playing field. I deliberately left the exotic performance options on the shelf — no FrankenPHP, no ARM, none of the tricks StoreFrame can pull.

Just a familiar, almost boring stack on plain x86 that any Magento team would recognise. The point wasn’t to win with something you’ve never heard of; it was to show how a setup everyone can relate to actually holds up. If it works on the boring stack, it works.

What I actually saw

You can scan them yourself:
fastartechniek.storeframe.store (Hetzner bare metal + StoreFrame Luma)
fastarshop.nl (Hyva + Hypernode)

At a glance, the Luma store doesn’t feel slow at all — it’s genuinely comparable. Try Add to Cart and filter on layered navigation, feels a snap on both.

On uncached pages, and especially in the backend, it’s actually a tad quicker.

The fastartechniek.storeframe.store demo stays online only through the end of June 2026.

Which sounds strange until you remember what’s underneath: raw bare-metal performance versus a managed hosting platform.

So the split is honest — we win on raw performance; Hypernode wins on stability, and Hyva wins on Lighthouse.

Here are the hard figures — three identical pages on each store (the homepage, a category, and the exact same product), five runs each:

Server response time (TTFB) — the bare-metal win

Metric	StoreFrame (Luma Based)	Hyva
Homepage	16ms	38ms
Category page	21ms	106ms
Product page	18ms	49ms

Google Lighthouse — mobile

Metric	StoreFrame (Luma Based)	Hyva
Homepage	55	66
Category page	51	47
Product page	51	90

Google Lighthouse — desktop

Metric	StoreFrame (Luma Based)	Hyva
Homepage	67	85
Category page	77	48
Product page	74	99

Measured early on a Sunday morning, around 5-6 AM CET — on purpose: that's when this B2B shop sees almost no real traffic, so neither store is fighting load. Google PageSpeed Insights (Lighthouse 13.3.0), median of 5 runs, across three identical pages — the homepage, a category, and the exact same product on both stores.

“Server response” is PageSpeed Insight's server-response-time. The Luma side runs lean and stock — no WebP, no CDN, no critical-CSS, no JS deferral — to keep it a level playing field; the Hypernode store is proxied through Cloudflare, so this is origin to origin. Lighthouse scores still swing ±10–15 run-to-run on these heavy pages.

Legacy site — the tuned Luma theme on StoreFrame bare metal (fastartechniek.storeframe.store). The table below is its 10 runs:

URL="https://fastartechniek.storeframe.store/"   # legacy: Luma theme, StoreFrame on bare metal
N=10
printf "%-4s %-13s %-11s %-13s\n" run "appconn(ms)" "ttfb(ms)" "srv-wait(ms)"
wait=()
for i in $(seq 1 $N); do
  read app ttfb <<< "$(curl -s -o /dev/null -w '%{time_appconnect} %{time_starttransfer}' "$URL")"
  sw=$(awk "BEGIN{printf \"%.1f\", ($ttfb-$app)*1000}")
  printf "%-4s %-13s %-11s %-13s\n" "$i" \
    "$(awk "BEGIN{printf \"%.1f\", $app*1000}")" \
    "$(awk "BEGIN{printf \"%.1f\", $ttfb*1000}")" "$sw"
  wait+=("$sw")
done
median=$(printf '%s\n' "${wait[@]}" | sort -n | awk '{v[NR]=$1} END{print (NR%2)?v[int(NR/2)+1]:(v[NR/2]+v[NR/2+1])/2}')
echo "----------------------------------------------"
echo "median server-wait over $N runs: ${median} ms"

run  appconn(ms)   ttfb(ms)    srv-wait(ms)
1    73.5          88.0        14.5
2    107.1         112.9       5.8
3    88.9          100.5       11.6
4    83.9          90.2        6.3
5    54.6          60.8        6.1
6    88.8          100.2       11.4
7    64.0          74.5        10.5
8    70.5          82.8        12.3
9    64.8          75.7        11.0
10   58.3          68.5        10.2
----------------------------------------------
median server-wait over 10 runs: 10.75 ms

Current production — the live Hyva store on Hypernode, behind Cloudflare (www.fastarshop.nl). The table below is its 10 runs:

URL="https://www.fastarshop.nl/"   # current production: Hyva on Hypernode (Cloudflare)
N=10
printf "%-4s %-13s %-11s %-13s\n" run "appconn(ms)" "ttfb(ms)" "srv-wait(ms)"
wait=()
for i in $(seq 1 $N); do
  read app ttfb <<< "$(curl -s -o /dev/null -w '%{time_appconnect} %{time_starttransfer}' "$URL")"
  sw=$(awk "BEGIN{printf \"%.1f\", ($ttfb-$app)*1000}")
  printf "%-4s %-13s %-11s %-13s\n" "$i" \
    "$(awk "BEGIN{printf \"%.1f\", $app*1000}")" \
    "$(awk "BEGIN{printf \"%.1f\", $ttfb*1000}")" "$sw"
  wait+=("$sw")
done
median=$(printf '%s\n' "${wait[@]}" | sort -n | awk '{v[NR]=$1} END{print (NR%2)?v[int(NR/2)+1]:(v[NR/2]+v[NR/2+1])/2}')
echo "----------------------------------------------"
echo "median server-wait over $N runs: ${median} ms"

run  appconn(ms)   ttfb(ms)    srv-wait(ms)
1    101.2         217.0       115.8
2    60.6          183.3       122.7
3    55.6          205.4       149.7
4    54.2          198.5       144.3
5    48.9          166.8       117.9
6    50.7          165.5       114.9
7    57.5          215.9       158.3
8    52.8          178.4       125.6
9    51.7          135.1       83.4
10   67.4          175.9       108.5
----------------------------------------------
median server-wait over 10 runs: 120.3 ms

A note on method: both snippets run from a single fixed host, so these are origin-side server-response times — not Google’s PageSpeed vantage. The legacy store is hit directly; the production store is Cloudflare-fronted (served dynamically, proxied to the Hypernode origin), so its figure includes that extra network hop and isn’t pure origin think-time. What’s comparable here is the run-to-run median and the size of the gap, not the raw milliseconds.

So who wins?

The honest answer splits along what you choose to measure. By TTFB — the time the server takes to answer at all — yes, we win, and not by a hair: uncached pages come back genuinely quick, and the cached ones land right alongside Hyva, near enough to call even.

All of that with nothing fancy under the hood — just a plain, properly tuned stack. But if the number you live by is the Lighthouse score, Hyva still takes it here. Both are true at once; pick the benchmark that matches what your store actually needs.

So did I actually win? On the one metric I set out to beat — raw server response — yes. Under the conditions I laid out (idle, cached, same page), a tuned Luma store on Hetzner bare metal answers faster than Hyva on Hypernode. And to be clear about the matchup: this is a Jackal S box (also Hypernode dedicated).

Most Hypernode shops I've seen run Falcon — their common tier — and Hypernode scales well past this into far heavier, far pricier configurations that "might pull ahead again", yet I doubt as OpenStack is another layer of virtualization. I'm not racing those. The point was never “I beat a great platform” — it's that fast doesn't have to be expensive.

If you have the budget, Hyva on Hypernode — and I mean that. It wins on Lighthouse, on the things Google rewards, on look-and-feel and the overall experience, and it’s built on newer technology that earns its price. (And if you genuinely want to go nuts on speed, Hyva on bare metal would be the ridiculous best of both — a post for another day.)

Two honest caveats. On SEO: yes, Hyva's stronger Lighthouse scores feed Google's ranking signals — though how much weight Core Web Vitals really carry today is anyone's guess; nobody seems sure anymore.

And on what I didn't measure: this was page-load speed, not load capacity — requests per second, behaviour under concurrency, tail latency at peak weren't tested here.

That said, the StoreFrame box runs more CPU cores (24 vs 12) at the same 64 GB RAM on dedicated bare metal — so on paper it has more headroom and should hold up at least as well under pressure. Theoretically. That's a benchmark for another day.

And you don’t even need bare metal to get here. Bare metal is the extreme — Fastarshop is a high-traffic store (more than 5 multi-sites), so it earns it. For most merchants, without that kind of traffic, a normal Hetzner cloud box with 64 GB of RAM is plenty: not quite as fast as raw bare metal, but comfortably fast enough. Same tuned stack, smaller bill.

And that’s only the comparison against the premium end. Plenty of Magento 2 stores still run on shared hosting — cPanel and the like — oversubscribed and creaking, sharing a box with who-knows-what, especially with the daily dose of ZeroDay we face today. Against that, a properly tuned cloud server isn’t a close call; it’s night and day. If that’s where you are, the jump is bigger than anything in this post.

So who is StoreFrame for? Merchants who’d rather keep their Luma store — whether that’s about cost or any other reason — but still want a faster, modern-performing alternative. Let the server do the work. If that’s you, that’s exactly where we can help.

One last thing. How does a plain server — root access, port 22, and nothing else — turn into any of this? That took me five years, and honestly it’s a story I haven’t seen told anywhere. I’ll give it its own post. Trust me on that one — stay tuned.

Rather keep your store and just make it faster? StoreFrame runs your existing Magento fully tuned on your own cloud — no re-platforming, no theme swap, operated by AI plus a human.

See how StoreFrame works

Hypernode Is Great at Magento Hosting. Why I Built StoreFrame Anyway.

Laurentius Judhianto — Tue, 02 Jun 2026 09:40:01 +0000

Hypernode is genuinely great at Magento hosting. So why did I build StoreFrame anyway? The answer was never about where a store runs.

I started where a lot of Magento people start: the frontend. I built themes, and for years that was the whole job. I was happy there — until I tried to grow past it and a Magento upgrade bit me, hard. (Hyva makes the theme layer a much nicer place to live now. I’ll come back to that.) The lesson stuck: if I wanted to keep clients fast and take on more of them without cloning myself, I had to look past the theme.

Honest confession: I’m not a backend developer. I still couldn’t tell you with a straight face what a private versus a public method really changes. So renting hosting — letting people who actually understand servers run the servers — was the only sensible call. Hypernode especially: secure, reliable, properly tuned for Magento. (Somewhere in the back of my head was a smaller, cheekier thought too: if I could ever match that for less, I’d pocket the difference. A solo dev is allowed to dream.)

Then the walls went up
I got curious about performance, and everything I reached for was locked.

A newer PHP version? Not yet. MariaDB instead of MySQL? This hosting doesn’t allow it. Swap Redis for KeyDB? Sure — except no root, so I couldn’t install it. Tengine, Alibaba’s nginx fork? I even tried building it from the makefile myself — nope, slow, and nowhere to run it anyway. The Elasticsearch plugin ElasticSuite needs? Off the table. Nope, and nope again. Every change that might have made a store faster ended at the same wall.

And it keeps happening. Today everyone’s talking about ARM and FrankenPHP — genuinely exciting for Magento. Where does a curious developer actually go to test them on managed hosting? Nowhere. You read the post and close the tab.

One layer at a time
So I stopped waiting for permission and started doing it myself — one layer at a time. First, a server I could actually log into as root. Then the stack on top, tuned by hand. Then I wanted to see what was happening — traffic, performance, what was slow and when — so I wired up Grafana and proper monitoring. Then it needed to survive a reboot. Then a second client, then a tenth — each one ideally identical to the last, so I wasn’t relearning every box. Every problem I solved uncovered the next one underneath it.

And I massively underestimated how hard running your own hosting actually is. There’s a reason managed hosts exist and charge what they do. For a while it felt like I’d traded a cage for a pile of pager duty — more freedom, yes, but every layer now mine to keep alive, alone.

And then AI arrived
And then it all made sense.

It started by covering the technical ground I don’t have. Building the HUB is genuinely hard, and I’d know: this is my third attempt at it. The first two never matched what I had in my head — this one finally did, across code, design, UX, and sheer completeness. AI closed the gaps I couldn’t close alone, and that on its own is worth a 10x engineer.

The StoreFrame HUB dashboard

The HUB, third time around — the one that finally matched what I had in my head.

So — did it scale?
That was the whole point: going from one solo developer to running more stores without becoming many people. Did it work? Yes. A standardised stack I fully control, plus an AI that closes the gaps I can’t, means I can take on more without drowning in it. Hypernode is still great Magento hosting — I built StoreFrame anyway because I couldn’t stop tinkering, couldn’t scale myself, and AI is what finally turned the whole pile of layers into leverage.

You can read more here storeframe vs hypernode

The one thing I haven’t put to the test here is raw performance — whether a setup like this can actually keep pace with the premium stacks. That’s the next post: a well-tuned Luma theme on Hetzner bare metal against Hypernode with Hyva. Stay tuned.