DEV Community: Laurentius Judhianto

After Building StoreFrame in NEXT.js, Headless Magento Will Make a Big Comeback

Laurentius Judhianto — Wed, 14 Oct 2026 09:50:55 +0000

PWA Studio, Vue Storefront, GraphCommerce, Rapidez, Breeze and Hyva: why headless Magento kept losing to cost, and why AI that writes JavaScript fluently may finally flip the verdict.

Headless Magento had a moment, and then it had a funeral. Ask my ex-colleagues about it. Magento developers have been chasing Lighthouse scores and a faster frontend since 2013, and most of us went back to the stack we already knew.

I was one of them: a Magento frontend developer stuck in the PHP world, knowing only a tiny bit of jQuery. NEXT.js was a foreign object. Then I built StoreFrame’s hub, and this site, www.storeframe.io, in NEXT.js. It is my first NEXT.js project. No joke. Somewhere in that build I changed my mind about the old headless debate, and the reason is sitting in my own codebase.

To explain why, we have to start with the original attempt, and why every attempt after it ran into the same wall.

Venia and PWA Studio: the original headless Magento

When Magento shipped PWA Studio with Venia as its reference storefront, it was the official answer to a slow Luma frontend: a React application, talking to Magento through GraphQL, with its own build pipeline and its own deploy. On paper it was the clean architecture. Magento becomes a commerce API, the storefront becomes a modern JavaScript app.

In practice, the complaint from web developers was always the same: you now needed two experienced developers. One who knows React, webpack and GraphQL. One who knows PHP, dependency injection and Magento’s module system. And those two people had to agree on every field, every resolver and every checkout step.

It got worse with extensions. The Magento module ecosystem was built for Luma. Every payment method, every shipping rule, every third-party module you bought had to expose its data over GraphQL and get a React counterpart before it worked in Venia. Many never did, so somebody wrote that bridge, by hand, store by store.

Adobe has since moved on. PWA Studio still gets maintenance and compatibility releases, but new storefront projects are pointed toward Edge Delivery Services instead. The original headless Magento is not dead. It is just no longer where anyone is building.

Vue Storefront: the community’s answer

Vue Storefront came out of the same frustration, from developers who wanted the Magento frontend fast and flexible, in Vue instead of React. For a while it was the exciting option, with a busy community and agencies building on it.

But it inherited the same bill: a separate JavaScript application, its own release cycle, and an integration layer to keep in sync with Magento. Over time the project went platform-agnostic, added a React kit, and in March 2024 rebranded as Alokai, positioned as a commercial frontend platform for many commerce backends. That may be a sound business. As the default way to build a Magento frontend, it never happened.

The alternatives that stayed

After those two, the ecosystem split into tools that chose a side: either fully decoupled, or as close to Magento’s own templates as possible.

GraphCommerce

GraphCommerce is a React and NEXT.js storefront that talks to Magento through GraphQL only. It runs as a separate application and is the most modern take on the Venia idea. It is also, honestly, still two stacks: you need the React side and the Magento side, and the GraphQL contract in between.

Rapidez

Rapidez takes a different route: Laravel, Blade and Vue, reading catalog data straight from Magento’s database and Elasticsearch, with GraphQL for the rest. PHP developers feel at home in it. But it is still a second application next to Magento, with its own deploy and its own upgrade path.

Breeze

Breeze goes the other way. It keeps Luma’s templates and layout and swaps the heavy JavaScript underneath, RequireJS and Knockout, for a much lighter runtime. Most Luma-compatible modules keep working. No second application, no second team.

Hyva

Hyva is the one that won, at least this round. Tailwind and Alpine.js, a fraction of the bytes, a good Lighthouse score out of the box, and the .phtml and XML layout every Magento developer already knew. One lean stack instead of two. Since November 2025 the theme itself is free and open source.

There is a reason everyone in this industry knows Willem Wigman, Hyva’s founder. In fifteen years, only a handful of people have been able to show real work on both sides, frontend and backend. Hyva won because it did not ask every team to find one of those people.

Why headless died: cost, not architecture

So let’s be honest about why decoupled Magento didn’t win. A fast frontend talking to Magento purely as a commerce API is a good architecture. It died on cost and complexity, which is how most good architectures die.

Most PHP developers don’t do JavaScript. Most frontend developers who know a bit of PHP don’t do React either. And plenty of experienced Magento backend developers can’t centre a div inside a div. So headless meant two hires, two skill sets and two codebases to keep in step, forever. Hyva gave most of the speed for one. Why on earth run two stacks when one gets you nearly there?

What changed: AI speaks JavaScript fluently

Here is why I think the funeral was premature. Ask the obvious question: what is an AI agent almost unfairly good at? JavaScript. TypeScript. React. NEXT.js. Tailwind. The exact stack a decoupled frontend is built from.

That is not an accident. JavaScript and TypeScript sit at the top of GitHub’s language rankings year after year, and the frontend world has rewritten itself every few years: jQuery, Backbone, Angular, React, Vue, Svelte, NEXT.js. Each wave left behind millions of public repositories, tutorials, Stack Overflow answers and migration guides. Models learned from all of it. Magento’s XML layout and .phtml conventions are a small corner of the internet by comparison.

For a frontend developer, that is a relief. The churn that used to drive us crazy, a new framework, a new router, a new build tool every two years, is exactly what the agent has already read. You describe the component; it knows the idiom of whichever version you happen to be on.

Web fundamentals: the copy-paste Lighthouse 100

This is the part nobody wanted to say out loud. With a headless NEXT.js frontend, getting an almost, if not perfect, 100 Lighthouse score is close to mechanical. Run Lighthouse. **__Copy the report*__. *Paste it into the prompt. The agent fixes what it lists: the LCP image without priority, the font that isn’t preloaded, the image without dimensions that shifts the layout, the JavaScript that ships but never runs. Run it again.

It works because in a headless frontend you own every byte on the page. Every Lighthouse finding points at code in your repository, in a framework the agent knows inside out. In a classic Magento theme the same report points into RequireJS bundles, third-party module templates and inline scripts you don’t own and can’t safely change. That loop is how I tuned this site, and it took minutes, not a sprint.

The fundamentals didn’t change: ship less JavaScript, size your images, load fonts properly, don’t block the main thread. What changed is the cost of applying them. It used to take a frontend specialist a weeks or months tweaking everything and breaking it over an upgrade. Now it takes an agent a coffee break.

Frontend and backend can finally work together

Remember the two-developer problem from Venia: two people, two stacks, and a GraphQL contract nobody wanted to own. That contract is where most headless projects bled time.

Now creating an API is a few prompts away. Need a GraphQL resolver for a custom module, or a REST endpoint for a checkout field? Describe it, let the agent write it, read the diff. Need the frontend to consume it? The same agent reads the schema and writes the typed client and the component. The backend developer doesn’t have to learn React, and the frontend developer doesn’t have to learn dependency injection. They meet at the contract, and the contract is cheap.

That is what happened to me. A Magento frontend developer with a bit of jQuery built a full NEXT.js product, with its API, websockets and dashboard, because the agent filled the half of the stack I never learned.

Claude Design: the Figma handoff disappears

The last piece is design. Claude Design, which Anthropic launched in April 2026, turns a prompt, a screenshot or your existing design system into a working prototype. Personally, I think it is a Figma killer, and the market briefly seemed to agree: Figma’s stock fell about 7% on launch day.

The reason matters more than the stock price. A Figma file is a picture of an interface that somebody still has to rebuild in code. What Claude Design produces is already HTML, CSS and JavaScript, and it hands off to Claude Code. Turning that into React components for a NEXT.js storefront is a short step, because it was never a drawing in the first place. Design, frontend and the API it calls now sit in one loop.

Why I picked NEXT.js over anything else

If AI writes the JavaScript, why NEXT.js and not something else? Fair question. Here is my honest answer, in four parts.

Shadcn, nothing more and nothing less. shadcn/ui is the component library I am sworn to. It was born in React and NEXT.js; the Svelte and Vue versions are ports. I want to be on the original, not the copy.
The ecosystem is more polished. Animation libraries like Motion (which started life as Framer Motion), frameworks, starter kits and tooling all land in React and NEXT.js first, and they are more finished there than anywhere else.
Explicit beats clever when AI writes it. Svelte might be easier, and Nuxt might be a lot better in many ways, if I were writing the JavaScript myself. But the agent writes most of it. When the agent writes and reads every line, an explicit, even verbose component it can see all of matters more than an elegant abstraction that hides what is going on.
The AI tools already speak React. Guess what v0, Vercel and Claude Design produce? React. When the tools that generate interfaces all default to the same stack, that is a strong hint about what the models know best.

And StoreFrame’s NEXT.js app isn’t another Hello World portfolio site. It isn’t even a simple CRUD app wrapped in auth and payments. Most of what happens inside it runs over websockets: live consoles, live deploy logs, live metrics streaming in from every store.

Almost nobody in the PHP world builds websockets. Magento leans on caching, and real-time is the exact opposite of a cache. So after taming that beast with an agent at my side, I am more than confident that NEXT.js is a solid choice when AI is writing the JavaScript.

Is this Hyva’s peak?

Every Magento frontend has had its period. Luma had one. PWA Studio had one. Vue Storefront had one. So it’s fair to ask whether Hyva will have its period too, and whether that is something to worry about.

Not tomorrow. Hyva is still a safe, fast choice for most merchants today, and nobody needs to panic about a store running on it. I’m not telling anyone to re-platform onto a headless build this afternoon.

But I’m skeptical it is the endgame. Every Magento frontend so far has been a bet on a niche skill: Knockout for Luma, React wired into GraphQL for Venia, .phtml with Alpine for Hyva. The pool of developers, and the training data behind every AI model, is overwhelmingly JavaScript. When the cost of a JavaScript frontend collapses, a stack built to avoid JavaScript loses its main reason to exist. At times, I'm as skeptical as staying on Magento too.

I’m on the headless bandwagon, 1000%

The thing that buried headless was economics, not architecture, and the economics just changed. When an agent can write the decoupled frontend, the API between the two halves and the design it starts from, the overhead stops being the dealbreaker it was. AI writes JavaScript like Magnus Carlsen plays blindfold chess.

So yes, I’m definitely on the bandwagon. StoreFrame’s own frontend already is: a NEXT.js app with the backend behind an API. Give the agents a few more turns of the crank, and a split frontend-and-backend Magento stops being the brave choice and becomes the sensible one.

I said in an earlier post that this was a story for another day. This is me starting to tell it. It isn’t mainstream yet. But for the first time in years, I’m betting on it.

We build StoreFrame’s own frontend in NEXT.js and run Magento underneath it — so when the headless math flips for real, we’ll be ready. Curious how we think about the stack?

See how StoreFrame works

Why We Migrated All Our Customers to Mage-OS. What Is Mage-OS Anyway, Compared to Magento 2?

Laurentius Judhianto — Wed, 07 Oct 2026 08:26:39 +0000

Every Magento merchant asks whether the platform will still be here, and still be free, in five years. We stopped answering shop by shop and moved every customer to Mage-OS. Here's why.

Every Magento merchant I know has asked the same question at least once in the last few years: is this platform still going to be here, and still be free, in five years? Answering it shop by shop got old. So we stopped answering it shop by shop, and moved every customer we run onto Mage-OS.

This is why, what Mage-OS actually is, and, to be fair, what still annoys me about the platform after all these years.

What is Mage-OS anyway?

Mage-OS is a community distribution of Magento Open Source. It started with the open letter The Future of Magento in September 2021, signed by more than 1,600 people, and is run by a registered non-profit association. The first distribution, 1.0.0, shipped in October 2023 on top of Magento 2.4.6.

Mage-OS 3.0 (May 2026) is built on Magento 2.4.9. So for a merchant it is still Magento 2: same architecture, same admin, and it aims to stay compatible with the extensions you already use. What changes is who decides what goes in, and how fast.

Magento Open Source is the free edition Adobe publishes alongside its paid Adobe Commerce. Adobe sets the roadmap.
Mage-OS takes that same core, keeps it compatible, and adds what the community agrees on: an interactive installer, admin activity logging, returns (RMA), AI-assisted translations, PCI DSS 4.0 features, and tools like n98-magerun2 in the box. No Adobe account needed to install it.

Why we moved every customer

1. The community is small, global and actually talks to each other

Mage-OS has regular technical calls on Discord, with developers from all over the world, and hackathons where people build genuinely cool things, like the one Made by Mouses hosted in Zwolle on 24 September 2026. If you are curious where the platform is heading, keep an eye on Mage-OS 4.

2. Your background matters less than your contribution

I am not a backend developer who can be compared to some of the veterans in there. But validating a bug, writing a clear issue and proposing a possible fix already helps. With AI today that isn't hard. What it does mean is checking three times before posting: is the fix right, is it really the root cause, and is there already a ticket for it? Nobody wants AI slop in their issue tracker.

3. The AI work coming next is worth waiting for

The Mage-OS 4 roadmap puts AI at the centre: a shared AI foundation, merchant tools, catalog generation, AI-powered search and recommendations. Next to that, Mago, a free open-source AI admin assistant built together with Mage-OS Nederland, already runs on Mage-OS 3. I'm watching that one closely, because it is exactly what we do at StoreFrame: AI agents doing the operations work.

4. Batteries included saves time and money

This one is personal. Most things should simply be there on day one, ready to use or automated. I hate day-two tweaking for things that could have worked the second the shop was installed. Mage-OS keeps pulling those day-two jobs into the box.

5. Adobe uncertainty

This one has been coming for a long time. A short history:

**2015: **Magento 2 goes GA, and Magento 1 merchants are told to plan a migration.
**2018: **Adobe buys Magento for $1.68 billion. Magento 1 support was meant to end in November 2018; it was stretched to June 2020, and on 30 June 2020 it ended. Many merchants rebuilt their whole shop because of a date they did not choose.
**2021: **Magento Commerce becomes Adobe Commerce.
**2025: **Adobe announces Adobe Commerce as a Cloud Service and Adobe Commerce Optimizer, both SaaS.
**Today: **Adobe's lifecycle and release pages are written for Adobe Commerce. Magento Open Source is barely mentioned.

Adobe has not said Magento Open Source is going away. It just says very little about it, and its energy clearly goes into SaaS. After the Magento 1 deadline, we would rather not bet our customers' shops on silence again. Mage-OS keeps the open-source core in community hands, whatever Adobe decides.

6. It's going to get faster and more adaptable

Mage-OS ships features every few months, and things like a worker-mode module for FrankenPHP are being built in the open. Some people clearly put a lot of their own time into this. Kudos to the Mage-OS board and the community.

What I still don't like about Magento

It wouldn't be fair to only praise it. After all these years, here is what still bugs me.

1. Installing and automating it from scratch is still painful

We solved it with our own wizard, and Mage-OS 3 added an interactive installer, which helps. But it is not at WordPress level yet, even with all these awesome people working on it.

2. Uncached pages are still slow, especially in the admin

Nebula, a modern admin theme from Qoliber built on Alpine.js and Tailwind, might be the thing that finally fixes the admin. But if I had to choose, the Laravel Filament way is a much better way to build an admin UI.

3. We should be heading to worker mode

FrankenPHP or OpenSwoole, with the application kept warm between requests. In our own tests FrankenPHP worker mode made single requests faster, but it is still nowhere near Filament or SPA speed.

4. It's not an SPA or PWA

Yes, yes, this one is personal preference. I don't like JavaScript and I will never write it by hand. But AI has been great at writing it, and coming from a UX and UI background, I think a fluent interface is one of the most important parts of the shopping experience and of managing a webshop. The micro-animations, the fluidity, the consistency of libraries like shadcn are priceless.

So, Mage-OS

None of this made us want to leave Magento. It made us want Magento in hands that will still be maintaining it, openly, in ten years. For us that is Mage-OS.

Self-Hosted Proof of Work with ALTCHA: A Turnstile Alternative for Magento

Laurentius Judhianto — Tue, 06 Oct 2026 12:48:42 +0000

One decision saved us setup time on every store, kept catalogue pages fast and stopped more bots: a self-hosted, Turnstile-style challenge that installs itself.

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

Cloudflare Turnstile is a lovely idea. Most visitors never see a puzzle. Their browser quietly proves itself in the background, and only the doubtful ones get asked anything. No traffic lights, no crosswalks, no squinting at a bicycle wondering whether the handlebar counts.

I wanted exactly that for every Magento store we run. Without the Cloudflare part, and, more importantly, without anyone having to set it up.

This post is about the one decision that ended up saving us time every day, making stores faster and making them safer, all at once. Three wins from one fairly boring decision. Those are my favourite kind.

The chore nobody puts on the roadmap

A captcha sounds like a five-minute job. For one store, it is.

Turnstile is set up per site, by a person: create the account, generate the keys, wire the widget into the store, register the domains. Then do it again for the next store. And the next one. And the staging copy of the next one.

That list hides the worst part: the sign-up. Before a single shopper sees a checkbox, Turnstile wants an account: register, confirm your email, add the domain, generate a site key and a secret key, install a Magento module to wire it all in, then discover the staging domain needs its own entry. All of that for a little box that says I am not a robot.

Then the back and forth starts. Emails to confirm, API keys to pass along, a module to install and keep updated. One person has the login, another has the store, and the keys live in an email thread nobody can find six months later. A domain changes and the whole dance starts again. Do that for a fleet of stores and you have a part-time job that nobody applied for.

Multiply that by every store you run and a captcha you set up by hand becomes a captcha someone, one day, forgets.

Shopping for an engine

So we went shopping. It turned out to be harder than building one, which we had already tried. Every option was good at something and wrong for us in a different way.

Google reCAPTCHA ships with Magento, so it was the obvious default. It also sends visitor data to Google, and on a bad day it asks your shoppers to find the bicycles.

Cloudflare Turnstile had exactly the right idea. But every store means the same round trip: an account, emails, API keys and a Magento module to install and keep updated, plus a vendor in the checkout path. Time and effort we did not want to spend, over and over.

Anubis is a whole proxy that puts every visitor through the puzzle. Brilliant for a code forge drowning in AI crawlers. Too blunt for a shop, where the visitor you challenge is often the one about to pay.

Cap came closest: open source, self-hosted, no image puzzles. It is deployed as a service of its own, though, which means one more thing to run and keep updated next to every store.

ALTCHA won on the boring things. It is open source, self-hosted and collects nothing, and it ships official libraries in both Go and PHP, the two languages our two layers already speak. So the same protocol runs twice on every store, by default: once at the edge, in front of everything, and once inside Magento, on the storefront forms.

Win one: time. It installs itself.

Both copies of ALTCHA are part of the store from the moment it is provisioned. The edge one ships inside our OpenResty container; the Magento one ships as a module in every shop's base package. No accounts, no keys, no widget to wire in, no checklist.

Every store runs the same protection, at the same version, from day one. Nobody has to go through a captcha integration, and nobody can forget to.

That is the daily saving. Not one big afternoon, but a long tail of small chores that simply never appear on anyone's list again.

Win two: speed. Bots pay before PHP does.

Here is the part people do not expect: the security layer made stores faster.

A cached product page is almost free. Catalogue search, or a category filtered by five attributes at once, is real database work. Bots love those pages the way toddlers love lift buttons: every combination, again, forever.

So a visitor who lands on catalogue search cold, with no history on the store, solves a small puzzle first. A shopper never notices; their browser does it while they read. The first burst this met came from 1,477 addresses. None of it reached PHP, and the server's load dropped from about 12.6 to 3.2.

On deep layered-navigation filters the price is dynamic: when a store is being hammered, the puzzle gets harder for everyone who has not earned trust yet. The share of abusive filter requests reaching PHP went from nearly all of them to 0.025%, with no real shoppers caught.

Every request the edge turns away is a PHP worker your shoppers get to keep.

Win three: security. Bots pay a toll.

If you read ZDNet's piece on Anubis, the open-source blocker that makes every visitor solve a proof-of-work puzzle, you will recognise the idea. Anubis is great, and honest about its limits: its own README calls it a bit of a nuclear response. In August 2025, Codeberg reported that AI crawlers had learned to solve its challenges.

We saw the same. One swarm solved our challenge 2,490 times out of 2,490. Politely. Instantly.

That is not a failure of proof of work, it is a misunderstanding of it. Proof of work is not a wall. It is a toll. A shopper pays it once, in a moment of CPU they never notice. A scraper pays it on every fresh session, forever, at whatever price the store is currently charging. And while it pays, every other layer is still watching: the fingerprints, the scoring, the crawler checks, the firewall.

Across multiple production stores over a given period, 404,149 visitors were shown the full challenge page, and 85.6% of them never solved it. The click-to-verify version, reserved for the highest scores, was solved by 3.1%. Which tells you who was getting it.

When we ask, and when we don't

The Anubis approach puts every visitor through the puzzle. For a shop, that is a conversion tax on the people you most want to keep. Nobody in history has ever checked out faster because of a captcha. So we only ask when:

It is a browser's first visit, invisibly, on the real page.

The score is doubtful, also invisibly.

The score is high, with a short interstitial that solves itself.

A cold visitor asks for an expensive page, before the query runs.

The store is under pressure, at a higher price for everyone not yet trusted.

Verified search engines never see it. Returning shoppers with a valid pass do not see it again for a while. And inside Magento, ALTCHA also replaces reCAPTCHA on the storefront forms, so they get the same treatment without a single traffic light.

How we got here, in three versions

Before any of this, the defence was rate limits and block lists. It had exactly two words in its vocabulary, yes and no, and was very confident about both. What was missing was a third answer: maybe. Prove it.

**Version one **was homegrown. Launch day took about twenty-five commits, most of them us changing our minds about who deserved a puzzle. I am not proud of that number.

**Version two **swapped our own cryptography for ALTCHA, because writing your own crypto is the kind of hobby that ends in a blog post titled lessons learned. Along the way we tried a classic squiggly-letters captcha and dropped it quickly: modern text recognition reads squiggly letters better than people do, so it was a test only humans could fail.

**Version three **settled on one rule: solving the puzzle is the browser test. Everything else only decides how hard we ask, never whether a real browser gets the chance to answer.

Was it worth not using Turnstile?

Honest answer: yep, 100%. Turnstile has something we never will: signal from a huge slice of the internet. If you are on Cloudflare already, use it and go outside.

We are not. For us, owning it means no third-party script on any page, no vendor in the checkout, no visitor data leaving the store, and a challenge we can tune per store when an attack changes shape. The price was three versions, a couple of embarrassing bugs.

I would do it again. I would just do it in one version instead of three.

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: *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.*

StoreFrame runs a self-hosted, Turnstile-style proof-of-work challenge at the OpenResty edge of every Magento store, priced by what each request costs, with no third party in the path.

See how StoreFrame protects Magento stores

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.