Skip to main content

Command Palette

Search for a command to run...

Cloudflare Workers Load Balancer: How I Built a Free AWS ALB Alternative in 22 Hours

Published
11 min read

The pricing problem that would not leave me alone

I have been working with Cloudflare Workers for a long time now. I have contributed to a few open source tools in the Workers ecosystem, deployed Workers in production, and pushed the runtime in directions it was probably not designed for. So when I say what I am about to say, understand that it comes from someone who actually likes the major cloud providers and respects what they have built. I am not some hater on the internet looking for something to dunk on.

But the load balancer pricing for small projects is genuinely indefensible.

If you go to AWS today and spin up an Application Load Balancer for a side project, you are paying somewhere between 18 and 24 dollars a month before a single user touches your application. That is roughly 16 dollars in fixed hourly fees just for the ALB to exist, plus a few more dollars in LCU charges for whatever traffic you do happen to push through it. Google Cloud Load Balancer sits in the same neighborhood. The AWS Free Tier exists, but it is only for new accounts and only for the first 12 months. After that the meter runs whether anyone is visiting your site or not. You are essentially paying rent on idle infrastructure, and the idle infrastructure has the audacity to be regional rather than global.

I noticed this pattern years ago when I was helping friends with their side projects. Every single one of them either ran their app on a single VM with no load balancer at all, or they swallowed the 20 dollar a month minimum and complained about it quietly. Nobody seemed to think there was a third option. And the more I worked with Cloudflare Workers, the more I realized the third option was sitting right there, waiting for someone to wire it up properly.

So last week I finally did it. I built EdgeBalancer, and I shipped it in 22 hours.

The actual decision to start

I want to be honest about something. I did not start this project because I had a grand vision or a business plan or a mailing list of people begging me to build it. I started it because I was bored on a Tuesday evening and I wanted to see if I could. That is the entire origin story. Curiosity, not ambition.

The basic idea was simple. Cloudflare Workers run on the edge in over 300 cities worldwide. They are cheap, they are fast, they have access to all the routing primitives you would need to do load balancing properly, and the free tier alone covers 100,000 requests a day before you pay anything. If you outgrow that, the Workers Paid plan is a flat 5 dollars a month that includes 10 million requests before any overage charges kick in. Compare that to AWS ALB, where you are paying 18 dollars a month minimum and that does not even include traffic charges. The math is not subtle.

The question was whether I could turn that raw capability into a tool that any developer could use without having to write a single line of Worker code themselves. I wanted them to log in, click a few buttons, and have a working load balancer pointing at their origin servers within a minute. That was the bar.

Architecture, briefly

The frontend is Next.js. The backend is Node.js with Fastify. Data lives in MongoDB Atlas Serverless, which I am running on a 100 dollar credit that Atlas gave me and that mathematically should last me about 99 years at my current usage. The backend itself runs on two Docker instances in Azure that I am paying for with student credits. And yes, in case you missed the joke, EdgeBalancer is load balancing its own backend. The tool eats its own dog food in production. That was not an aesthetic choice as much as a practical one. If my own load balancer cannot handle traffic to my own API, then I should not be asking anyone else to trust it.

The actual load balancing logic lives inside Cloudflare Workers that get deployed dynamically when a user creates a new balancer. When you fill out the form in the dashboard, the backend uses your Cloudflare API token to provision a Worker script under your own account, attach it to whatever zone and route you specified, and configure it with the strategy you picked. Round robin, weighted round robin, IP hash, sticky sessions, weighted sticky, failover, geo steering. All of them are implemented as different code paths inside the Worker template. The Worker reads its configuration from Workers KV and routes requests accordingly. Origins, weights, health, all of it lives in KV so updates are instant and global.

The reason this is important is that the Worker runs in your Cloudflare account, not mine. EdgeBalancer is essentially a control plane. The data plane belongs to you. Your traffic never touches my servers. Your API token never leaves your account except to make calls to Cloudflare on your behalf, and even then it is scoped down to the absolute minimum permissions needed. Worker Script Edit, Worker KV Edit, Zone Read. Nothing else. If you are paranoid about giving any tool access to your Cloudflare account, those are the only three permissions you need to grant, and you can revoke them whenever you want.

The 22 hour part, and the part where I admit I cheated

This is where I get a little uncomfortable, because I want to tell the truth even though the truth is going to make some readers angry.

I did not write most of the frontend myself. I am a backend engineer. I have a complicated relationship with CSS, and an even more complicated relationship with whatever the current React state management hot take is. So when it came to building the Next.js dashboard, I leaned almost entirely on Codex CLI and Copilot CLI. I described the screens I wanted, gave them the design constraints, pasted in screenshots of layouts I liked, and let them generate the components. I reviewed everything they wrote, corrected what was broken, and pushed back when they did something silly. But the initial drafts were not mine.

The backend was different. The Fastify routes, the Cloudflare API integration, the Worker template, the KV configuration logic, the strategy implementations, all of that I designed myself because that is the part I actually care about. But even then, I used Claude Code to generate boilerplate, Gemini CLI to sanity check edge cases, and Copilot CLI to write the dozens of small utility functions that nobody enjoys writing. Anywhere a function felt obvious or repetitive, I let an AI write the first draft and then I cleaned it up.

I want to be clear about why this matters. 22 hours is not a humble brag. It is a number that would have been completely impossible for me to hit five years ago, even with the same skill level I have today. The reason it was possible now is because the tedious parts of software engineering have started to evaporate. The interesting parts, the design decisions, the architectural tradeoffs, the choice of which features to ship and which to cut, those still require a human brain. But the part where you sit down and write the 47th REST endpoint of your career, that part is going away. I am not sad about it. I am thrilled about it. It means I get to ship more of the things I actually wanted to build.

If you are a developer reading this and you are still writing every line of code by hand because it feels more honest, I respect the discipline, but I think you are leaving a lot on the table. Use the tools. Review their output carefully. Ship more things.

What you can actually do with it

Once you log in with Google or with email and password, the very first thing EdgeBalancer asks for is your Cloudflare account ID and a scoped API token. Without those, the app refuses to take you to the dashboard, because there is nothing for the dashboard to show you. Once you connect, the system makes a quick test call to fetch your available domains, both to verify the token works and to populate the domain selector for the next step. If anything fails, you get an error and a chance to fix it before going further.

From the dashboard, you create a new load balancer by giving it a name, picking a domain you own in Cloudflare, optionally specifying a subdomain, adding your origin servers, and choosing a routing strategy. There is also a worker placement option called Smart Placement that tells Cloudflare to run your Worker physically closer to your origin infrastructure, which can shave real milliseconds off backend latency for chatty APIs. You hit create, and a few seconds later your load balancer is live across the entire Cloudflare edge network.

Managing the balancer is just as simple. You can edit it, delete it, or pause it. The pause feature has two modes that I am genuinely proud of. The first is a maintenance mode that keeps the domain attached and serves a clean maintenance page to all visitors, which is useful when you are doing planned downtime and want a fast resume. The second is a hard stop that fully detaches the domain from Cloudflare, which is what you want when you are decommissioning something permanently. Most load balancer products only give you on and off. Two thoughtful modes are a small thing, but they matter when you are the one paged at 2 a.m.

The "is this basic" question

I already know what some of you are thinking, because I had the same thought myself while I was building it. Bro, this is a basic project. A web form that calls the Cloudflare API and provisions Workers. How is this even worth writing a blog post about?

Here is my answer. Basecamp is a glorified to-do list, and it has been charging real money for over twenty years. ConvertKit is a glorified email scheduler. Todoist is a glorified text file. Notion, in its earliest version, was a glorified rich text editor. The list of "basic" products that quietly pull in millions of dollars a year by solving one specific annoying thing really well is enormous. Simple is not the opposite of valuable. Simple is often the entire point. The only reason these tools feel basic in retrospect is that someone, somewhere, took the time to actually build them properly while everyone else was busy explaining why the idea was too obvious to bother with.

I am not claiming EdgeBalancer is going to be the next Basecamp. It is a side project I built in 22 hours. But the underlying instinct, that solving one boring problem well is worth doing, is one I want to defend. There are too many developers sitting on a pile of "too basic to ship" ideas while other developers ship those exact same ideas and build real businesses on top of them.

Where this goes from here

For now, EdgeBalancer is free. You bring your own Cloudflare account, you pay Cloudflare directly if you outgrow their free tier, and the management layer itself costs you nothing. I am keeping it that way for the foreseeable future because I want people to actually use it and tell me what is broken. If it grows into something bigger, I will figure out a sustainable model later. If it does not, I will have learned a lot and I will have a load balancer running my own backend for free, which is more than fine.

If you are a solo developer, an indie hacker, or anyone running a side project on a tight budget, give it a try at https://edge.nexoral.in. The whole flow takes about 60 seconds. And if you find something that does not work the way you expected, please tell me. Brutal feedback is the only kind I find useful.

The boring infrastructure should be cheap and fast. That is the only opinion I am really trying to defend here. Everything else is just code.

1 views