Choosing Cloudflare Workers for Lightweight SaaS Infrastructure

Infrastructure choices are often framed around how much a platform can scale. For the products I work on, I find a different question more useful: how much infrastructure does this product need me to operate?

That question led me to Cloudflare Workers. It puts application code and static assets close to the public web while giving a small project a short path from a repository to a deployed service. It is a practical fit for some of the lightweight, web-facing work I do through Axiom Labs, but I do not see it as a universal answer.

The infrastructure question

A small software product still needs dependable deployment, TLS, routing, caching, security controls, and useful failure behaviour. The catch is that every moving part has an operating cost. A service can be inexpensive to provision and still demand a lot of attention.

I wanted an approach that kept that surface area small. In particular, I did not want to maintain a server merely to deliver static files or run a compact request handler. I also wanted preview and production releases to follow the same basic deployment model.

I was not responding to massive traffic or an enterprise workload. I was choosing to spend limited engineering time on the product instead of routine server management.

Why Cloudflare Workers made sense

Workers combines an edge runtime with the surrounding Cloudflare network. When an application fits that model, a request can be handled near the user without first passing through a server I have to provision, patch, and keep running.

I find the static-assets model especially useful for content-first products. A build can produce HTML, CSS, and images ahead of time, then Workers Static Assets can serve them directly. If a project later needs a small amount of request-time behaviour, the Worker runtime is available without turning the static site into a traditional server application.

That shape matched my constraints:

• deployments should be repeatable from source control;
• public assets should be cached efficiently;
• HTTPS and edge delivery should be part of the platform;
• runtime code should exist only where the product actually needs it.

For me, the important decision was not simply to use an edge platform. It was to keep the application static where possible and reserve runtime execution for genuine dynamic work.

What I liked about the platform

The deployment path is compact. Wrangler gives me one command-line interface for local development, configuration, preview versions, and releases. That reduces the gap between what the repository describes and what is deployed.

I also like that static assets and request handling can share a platform while remaining distinct. Static files do not need to pass through application code. That is good for performance and removes code from a path that does not need it.

The smaller surface area helps with security too. Managed TLS, a network edge in front of the application, and explicit response-header configuration give me useful building blocks. I still need to review permissions, secrets, caching, content security policy, and application behaviour, but I am not also responsible for securing a general-purpose server.

That matters on projects where infrastructure is part of the work rather than the product itself. My broader selected work reflects the same preference for dependable systems with an operating model a small team can understand.

The trade-offs

Workers has its own runtime model, APIs, limits, and debugging habits. Code written with assumptions from a long-running Node.js server may need to change. Some libraries expect filesystem access, process-level state, or APIs that do not map neatly to an isolate-based runtime.

Edge execution can also encourage premature distribution. Data still has a location, and moving computation closer to a user does not automatically make every database interaction faster or simpler. A globally distributed request layer paired with a poorly considered data path can add complexity rather than remove it.

There is also platform coupling. Wrangler configuration, Workers bindings, and Cloudflare services are useful because they integrate well, but each deeper integration raises the cost of moving elsewhere. I try to keep product logic separate from platform-specific entry points when that boundary is worth maintaining.

When I would choose something else

I would reconsider the platform if a product depended heavily on a conventional server runtime, needed specialised long-running processes, or relied on libraries and operational tools built around another environment. A managed container or application platform may be a clearer choice in those situations.

I would also look elsewhere when the main constraint is data residency or a database topology that does not align with an edge request layer. I want the infrastructure to follow the product’s hard requirements, not force those requirements into an awkward shape.

For an uncomplicated static site, even a Worker runtime may be unnecessary. Cloudflare’s static-assets path is useful precisely because it can serve the build without invoking application code.

Lessons learned

What I value about lightweight infrastructure is not that it makes operations disappear. It makes the responsibilities that remain easier to see.

For these projects, I have found Cloudflare Workers most effective when I pair it with restraint: precompute what can be static, keep request handlers small, document platform assumptions, and add services in response to evidence. The trade-off is working within a specific runtime and accepting some platform coupling. In return, I get a deployment and delivery model that is small enough to reason about and capable enough for the problem in front of me.