One9x Pages is purpose-built end to end: edge, routing, storage, control plane. It runs on bare metal in a data centre — not AWS, not GCP, not Azure, and not a platform layered on top of one.
The question I keep getting is why. Why build all of it in 2026, when the cloud already solves this and every sensible person tells you not to. This is the long answer. I think it’s worth reading even if you never touch what I built, because most of the reasoning is about where your own things should run, not about my product.
The fair thing to settle first is why you should listen to me at all.
I’ve spent my career selling three things to employers: lower latency, lower cost, and systems that stay up. That’s been the pitch since my first job — and the first job is where most of this actually comes from.
We were building something that needed low latency and a lot of data processing, and it ran on machines sitting in our own data centre. Deployment meant logging into them. Not a pipeline — SSH, and in some cases a Windows login, across fifty-odd boxes, one at a time. We also wrote our own service discovery layer on top of the application, because nothing mature existed yet. It worked, and it worked well. That job is where I learned how deployments actually happen, how a distributed system behaves when nothing is hiding it from you, and what a data centre is.
Then Kubernetes arrived and blew my mind. Deployments that had meant fifty logins became one command. Rollouts, CI/CD, service discovery — all of it built in and handled for you. After the manual years it didn’t feel like a tool. It felt like being let off a leash.
Then I joined startups, and we did what everyone did: put everything on Kubernetes or ECS, because why would you not. The bill was large enough to be a threat to the company itself. So we started pulling things back out. The secondary database, the caching layer, anything that didn’t genuinely need orchestration went onto plain EC2 and we ran it ourselves — which I could do, because of the first job. Only what actually earned its place stayed managed.
That’s the judgement I’ve been making ever since, and I own the deployment side of it, not only the design. I’m the one deciding where a thing runs, and that decision is where nearly all of the cost saving comes from — far more than any optimisation inside the code. Sometimes managed is the right answer and I’ve argued for it. But the reflex that managed is safe and self-hosted is reckless is wrong often enough, and expensive enough, that being able to make that call honestly has been worth more to my employers than any diagram I’ve drawn.
Most of that work has been migrations — moving old services onto new ones without breaking anything, and taking out complexity that never needed to be there. On those I do the high-level design, but I also write the code. High-level design is the easy part; anyone can draw the boxes. It’s the low-level design where each decision carries weight, and writing it myself is where the context comes from that makes the high-level calls correct in the first place.
I should be honest about how I learned that. I built the complexity too. Microservices where a single service would have been fine, split for reasons that sounded right at the time and didn’t survive contact with production. I wasn’t outside that pattern criticising it. I was doing it, and then I spent years on the other side, unpicking that kind of decision in other people’s systems.
Then I moved into high-frequency trading, and it took the big blocks away entirely. No distributed architecture to hide behind, no orchestration layer, nothing to spread a problem across. One machine, hard constraints, and low-level design is all that’s left. In that world the only thing that wins is fast, and the fastest program is almost always the simplest one. You cannot over-engineer your way to low latency — every abstraction is something you pay for in nanoseconds. HFT didn’t teach me to build bigger. It taught me to see what’s actually necessary and delete everything else.
Two things pushed me from there toward building this. Watching Netlify gave me the shape of it. A home lab gave me the argument.
Netlify made me question something I’d stopped noticing. They took static hosting — the simplest possible thing — and built a real company on it. The lesson wasn’t about hosting. It was that a simple product can work, and that complexity is not the same thing as ambition. The question that stuck was: why can’t most things be that simple? Because when you look at what people actually host, it’s blogs, marketing sites, commerce, portfolios. That’s the bulk of the internet, and most of it does not need the machinery we’ve built around it.
The bill that broke the spell
Pulling workloads back onto EC2 saved money, but it left a question I hadn’t answered. I’d assumed the cost was Kubernetes — that orchestration was inherently expensive, that self-hosting a database was worse than paying someone, that this stuff was beyond a small team to run properly.
So I started a home lab, mostly out of stubbornness. I ran Kubernetes on it. I worked out how BGP works for MetalLB, how to assign multiple IPs, how load balancing actually behaves when nothing is abstracting it for you. And the more of it I built by hand, the more the mystique drained out.
The thing that fell out of it was that the cost was never Kubernetes. Kubernetes on hardware I controlled cost almost nothing to run. The cost was the managed layer underneath it — the cloud the cluster was sitting on, sold as a service, priced accordingly.
Which gives you the belief the whole product rests on: a server isn’t expensive. The polished layer on top of it is. That layer is what we call cloud, and it’s a genuinely good product — it sells usability, and it sells an idea about scale. But you are paying for the layer, not the machine. One9x is the straightforward conclusion: rent the metal at the bottom, build the platform on top of it yourself, and skip the layer in between.
The SLA thing nobody says out loud
AWS is job insurance. That’s what a lot of people are actually buying. Not reliability, not elasticity — cover. Nobody gets fired for picking the big cloud. You do get asked hard questions for picking your own hardware, even when it stays up longer.
Smaller providers sometimes give you a better effective SLA than a hyperscaler does. Not because their engineering is better, but because a hyperscaler’s SLA is conditional on you building a specific architecture — multi-AZ, the right redundancy, the right failure handling. Most teams don’t build that. They deploy to one region, one zone, one instance, and assume that because it’s running on a big cloud, it’s covered.
It isn’t. You inherited the logo, not the guarantee.
I don’t have that problem anymore. Nobody’s going to fire me for this. Which means I get to choose what’s actually right rather than what’s easiest to defend, and it turns out those were different answers all along.
And that connects to something else I kept noticing. My rough estimate is that the large majority of startups don’t need hyperscale elasticity at all. They’re running a single instance. They know roughly what their traffic looks like. They are not going to wake up to a million requests overnight. They’re paying for optionality they will never exercise.
Then AI changed the shape of the problem
Two things happened at once.
The first is that people who don’t write code started building software. I don’t mean industry veterans experimenting. I mean my cousins. Fresh graduates. Friends, and friends’ families. They’d build something genuinely decent, and then hit a wall at deployment.
They’d start with a free tier at a big cloud, doing everything the right way, and then discover that setting up a cloud account is its own skill. So they’d come to me, or to someone technical they knew, who’d come to me. And the complaint was always the same: this is expensive, and I only wanted to try things out.
So I gave them space on my home lab. Free, informally, because I already had the hardware running. That demand was real and nobody asked me to go find it.
The second thing is that AI raised the volume everywhere by an order of magnitude, sometimes several. Look at what’s happening to infrastructure everyone treats as permanent — code hosting, mail, the basic primitives. When traffic goes up 10x, 100x, 1000x, those systems strain. That isn’t a weak product. It’s a pricing and capacity model that was sized for a world with far fewer builders in it.
Which leads to the part that actually convinced me this was a business and not a hobby:
AI can rewrite your library. It can rewrite your algorithm. It can rewrite your entire application. It cannot remove the need to run the thing somewhere.
Infrastructure is the layer that gets more necessary, not less. That’s an unusual position to be in right now.
The colocation moment
I have a cousin who works in network IT services. He built his own ERP system with AI help, but his instinct is hardware rather than software — he knows machines, racks and networks, and has no particular interest in cloud.
We started by putting machines in his flat. That lasted until we did the arithmetic on electricity and maintenance and realised it was more expensive than doing it properly. As he supplies IT services, some of his clients run data centres, so we asked them about colocation.
The pricing we got back was for actual hardware. Not hardware plus a platform, plus a control plane, plus a margin. Just the machine, with power, cooling, maintenance, and a real SLA attached. What you don’t get in that deal is the big-cloud layer on top — the exact layer I’d spent years deciding I didn’t want.
To be clear about how I got that price: my cousin knows these people, and that helps. Worth saying, because someone will check. But the more useful fact is that this is the single-machine rate. Rack-level pricing goes down substantially from there, so the economics get better as this grows, not worse. And hardware failure isn’t my problem — replacement is part of what the facility provides. That’s the thing people assume you give up when you leave the hyperscalers, and you don’t.
Roughly: a machine costs me somewhere around ₹50,000 a year. Getting equivalent capability from a hyperscaler runs into thousands of dollars a month. I’m not going to pretend that’s a like-for-like comparison — it isn’t, and anyone who’s operated both knows why. But the gap is not 20 percent. It’s a different order of magnitude, and it changes what’s possible to offer.
Where that gap actually comes from
A number that large invites a fair suspicion: either I’m cutting something, or I’m comparing dishonestly. So let me show where it comes from, because the answer is structural and it matters more than the number.
First, what I’m not claiming. “We’re the cheapest” is a weak thing to be — anyone can undercut you, and it usually means you have nothing else to say. The price isn’t the strategy. It’s a consequence.
Let me be accurate about this, because it would be easy to overclaim. I rent too. Rack space, power, cooling, connectivity — all of it is rented from the facility. Nobody in this business owns the whole chain.
The difference is where you sit in that chain. Vercel and Netlify are the clearest examples, and I say that as someone who admires both — they are excellent products, and they are also convenience layers running on infrastructure they rent from someone else. That infrastructure is often itself layered: a cloud that leases capacity, a CDN rented from somebody else, a platform built on top of both. Every link adds a markup, and by the time it reaches the customer there are several stacked up.
I rent at the bottom of that stack instead. Hardware and facility, direct from the source, and everything above it I built. That doesn’t make me exempt from economics. It means there’s nobody in between adding margin to margin.
That’s what makes the platform economical rather than cheap. It means a free tier that’s actually usable instead of a trial in disguise. It means no per-request billing and none of the low-grade anxiety that comes with watching a meter.
What I decided to build, and what I decided not to
I made one hard call early: no VPS, no raw compute.
The people I started this for don’t want a server. They want their thing to be online. If they have to think about a machine even once, I’ve failed at the part that matters. So it’s serverless, and the constraint is deliberate.
The first thing I actually built under this name was WP Serverless. I’d worked the problem out on paper well before that — I wrote up a design for hosting a million WordPress sites in June 2025, and that post is still up. Then I built a proof of concept, and at the scale I tested it, it did what it was supposed to do.
It’s worth reading that post against this one, because the design I landed on then was Kubernetes, distributed storage, autoscaling pods, a managed serverless database. The observations underneath it were right, and one of them turned out to be the most important thing I’ve built since: a million WordPress installs is fifty terabytes of identical core files, so store the core once and point everything at it. That’s content-addressed storage in embryo, arrived at well before I built it properly. But the machinery I wrapped around those observations was mostly solving problems the cloud had created in the first place. It took the home lab to see that.
What stopped me wasn’t the product. It was the order of operations. WP Serverless means solving PHP execution, persistent state, database, and caching all at once — and none of it could sit on anything, because the storage layer, the gateway and the control plane underneath it didn’t exist yet. Every problem I hit was really two problems, and I couldn’t tell whether the fault was in WordPress or in the foundation I was building at the same time.
So static sites came first instead. The demand was already there and it wasn’t hypothetical — people were asking me to host things before I had anything to host them on. Static is also the simplest surface to get right, which means the foundation gets built properly and gets proven before anything harder sits on top of it. WP Serverless isn’t abandoned. It’s queued behind the infrastructure it needs.
Owning the network end to end was a decision from day one. Not because scale demanded it — there was no scale then, and honestly there’s still no number on my dashboard today that would force the question. It was a decision about what the platform is. When you run the path yourself, bandwidth and delivery economics look nothing like they do on a rented CDN, and that’s only true if you own it from the start. So reaching for someone else’s edge was never on the table.
That decision is what ruled out the obvious shortcut. I looked hard at assembling something from existing pieces — nginx, Apache, HAProxy, the usual proxies. And I could have. But configuring a general-purpose proxy means the interesting behaviour of your product lives in a config file. That’s fine until you want something the config language doesn’t express: a caching rule tied to content hashes, a certificate lookup against your own tenant store, a routing decision made fresh on every request against a database of custom domains. Multi-tenant hosting is made almost entirely of those cases. At that point the config file isn’t saving you work, it’s constraining you, and you end up writing modules for someone else’s program or bolting a second process onto the request path.
So here’s what actually runs, since “built from scratch” is a claim people make loosely and it should be checkable.
There is no nginx in the request path. No Apache, no HAProxy, no proxy with configuration wrapped around it. The edge is Pingora — Cloudflare’s Rust framework — and everything above it is mine: routing, caching, request handling, certificate resolution against the custom-domain store, range requests, compression, SPA fallback. Behind the edge sits a Patroni-managed Postgres cluster as the control plane, with content-addressed storage underneath. Traffic reaches the edge through an anycast VIP with kernel-level ECMP spreading it across a fleet of edge processes, health-checked so an unhealthy one removes itself from rotation. Certificates are issued automatically over ACME for custom domains onboarded by CNAME. All of it runs on Proxmox on the rented metal.
Using Pingora rather than writing my own proxy is the same judgement inverted. TCP, TLS termination, connection pooling, async IO under load — solved, brutally well tested, and getting them subtly wrong costs you correctness in ways you find out about in production. There’s no product value in my version of that. There is product value in my version of everything above it.
I’m not interested in reinventing wheels. I am interested in owning the assembly. That distinction is the whole thing.
I started storage with a plain file-based layout, because static sites are simple. That was wrong, and what showed me was watching how people actually deploy. They don’t upload a site once. They push the same site forty times in a week, changing a heading, and every push is nearly identical to the last one. There’s a second layer to it too: sites built with modern frameworks share enormous amounts of identical content with each other, not just with their own previous versions — the same libraries, the same vendor chunks, the same fonts, across thousands of unrelated deployments. Treating every site as an isolated pile of files throws all of that away twice over.
So I moved to hash-based, immutable, content-addressed storage. Content is stored once and referenced by hash, regardless of how many deploys or how many customers point at it. A rollback becomes pointing at an older set of hashes rather than restoring anything. The idea comes from object storage, but object storage adds latency I can’t afford here. Static hosting has one job and that job is to be fast.
Where this goes
Back to the question Netlify put in my head. They started as a static site company — narrow, simple, one thing done well — and from there expanded into functions, edge, commerce, without ever losing the simplicity that made the original thing work. That progression only works in that order. You earn trust at the narrow end first. Functions, edge, commerce, a database — none of it is interesting until static hosting is genuinely solid and people believe it will stay up. So that’s the order I’m following.
One9x Pages is live. Static hosting, free tier, custom domains. You bring your build and we serve it — there’s no CI pipeline in the middle to queue behind or pay for. If you’ve got something sitting in a repo that never made it online because the deployment step wasn’t worth the trouble, that’s exactly the person I built it for.
Try it. Tell me where it breaks.