Cloudflare Workers: what are they and how to use them

Business applications must serve increasingly distributed users, customers, and employees without turning every new project into a server management exercise. Cloudflare Workers was created to address this need: it allows code to run across Cloudflare’s global network, bringing part of the application closer to the person using it.

Workers is not simply a service for creating small functions. It is the central compute layer of the Cloudflare Developer Platform and can coordinate databases, object storage, stateful services, containerized applications, and static resources. This makes it possible to build a virtual infrastructure without directly managing machines, operating systems, or clusters.

This guide explains what Cloudflare Workers are, how they work, and in which scenarios they can be useful to a business. The goal is not to explore programming details, but to provide the information needed to evaluate their advantages, limitations, and architectural impact.

What Are Cloudflare Workers?

A Cloudflare Worker is a serverless application executed within the Cloudflare network. The code is deployed across the edge infrastructure and is activated when it receives a request or when an event defined by the application occurs.

In a traditional infrastructure, a request must reach a server located in a specific geographic region. With Workers, Cloudflare can execute the code in a location close to the user, reducing the distance the request needs to travel. The company does not need to select a machine, install an operating system, or manually size a group of servers.

A V8-Based Runtime, Not a Node.js Server

Workers runs JavaScript and TypeScript through a runtime based on the V8 engine, the same JavaScript engine used by Chromium. It does not start a complete Node.js process for every request. Instead, it uses isolated environments called isolates, which can be created quickly while safely sharing the resources of the underlying machine.

The runtime supports Web standards and a subset of Node.js APIs. The nodejs_compat mode extends compatibility and makes it possible to use many libraries from the Node ecosystem, but it does not make Workers equivalent to a traditional Node.js server. Before migrating an existing application, it is therefore necessary to verify the dependencies being used and the required functionality.

Edge Computing: Running Code Close to the User

Edge computing refers to executing code at points in the network that are closer to users instead of exclusively within a central data center. This model can reduce latency and improve perceived performance, especially when an application serves people across different countries or continents.

Not every operation necessarily needs to run at the edge. A Worker can immediately process a request, apply security rules, query a cache, or forward the workload to a database or central service. The advantage lies in being able to decide which activities should be distributed and which should remain within the existing infrastructure.

How Cloudflare Workers Work

From the User Request to Worker Execution

When a request reaches Cloudflare, the platform identifies the Worker associated with the requested domain or path. The Worker can generate a response directly, modify the request, query a service, or retrieve content from an external origin.

This allows Workers to be used either as a complete backend or as an intermediary layer in front of existing systems. A company can, for example, introduce authentication, access control, caching, or data transformation without having to immediately rewrite the entire application.

A Platform Distributed Across Cloudflare’s Global Network

The code is not associated with a single server managed by the customer. Cloudflare distributes it across its own network and automatically manages availability, instance startup, and the capacity required to handle traffic.

This model eliminates many operational tasks, but it does not eliminate the need for good application design. Data, consistency, external dependencies, and database location still affect overall performance. Moving the code closer to the user does not automatically move a database hosted in a single region closer as well.

What Can Be Built with Cloudflare Workers?

APIs, Backends, and Application Gateways

Workers can expose APIs, manage backend logic, compose data from multiple sources, and apply rules before a request reaches corporate systems. They can be used as a gateway to standardize different services and provide the frontend with a consistent interface.

This approach is useful when modernizing legacy applications: the Worker can become a controlled layer between new digital channels and existing services, enabling a gradual migration instead of an immediate replacement.

Authentication, Redirects, and Request Transformation

Some of the most immediate use cases include credential verification, permission management, redirects, response personalization, and data normalization. The logic is applied before the request reaches the origin server, reducing the workload on central systems.

Globally Distributed Business Applications

Workers is particularly interesting for international portals, SaaS platforms, multitenant applications, and services used by offices located in different geographic areas. The same application codebase can be distributed globally without manually replicating a traditional infrastructure in every region.

Workers and the Cloudflare Ecosystem

The value of the platform becomes especially clear when Workers is combined with other Cloudflare services. The Worker manages application logic and accesses resources through explicitly configured connections called bindings.

Bindings Between Workers and Cloudflare Services

A binding makes a resource directly available to Worker code. It can connect a D1 database, an R2 bucket, a Durable Object, a Hyperdrive service, or a Container without exposing credentials in the code and without requiring every integration to be built as a conventional public API.

Bindings turn Workers into an infrastructure coordination layer. The configuration defines which resources the application can use, while Cloudflare manages authentication and internal routing.

Cloudflare R2 for Files and Object Storage

R2 is Cloudflare’s S3-compatible object storage service. It can store images, documents, backups, user-generated files, and other unstructured resources. A Worker can read or write these objects through a binding and apply access controls before delivering them.

R2 is particularly interesting for applications that transfer large volumes of data because it does not apply traditional data egress fees to the Internet. Storage costs, operations, and the overall architecture must of course still be evaluated.

Cloudflare D1 and Horizontal Database Scalability

D1 is a serverless SQL database based on SQLite and integrated with Workers. It provides a familiar relational model without requiring the direct management of a database server. It is suitable for portals, business applications, catalogs, configuration systems, and many SaaS projects.

It is important to understand its sizing limits. On the Free plan, each database can reach 500 MB, with 5 GB available overall per account. On the Workers Paid plan, the limit is 10 GB per individual database, with total availability normally equal to 1 TB per account. These values are sufficient for many common projects, but larger systems require conscious architectural planning.

D1 is designed to scale horizontally through multiple smaller databases. In a multitenant application, for example, a database can be assigned to each customer, group of customers, user, or application entity. This is not a mandatory rule: the partitioning strategy should reflect isolation, volume, and workload requirements.

Each individual D1 database processes queries sequentially. Distributing data across multiple databases therefore also distributes the workload, while proper indexes and efficient queries remain essential for maintaining good performance.

Cloudflare Hyperdrive for Connecting Existing Databases

Not every company can or wants to move its data to D1. Hyperdrive allows Workers to connect to existing PostgreSQL and MySQL databases while improving connection management and reducing the impact of the distance between distributed code and a central database.

It is a useful solution when a company wants to adopt Workers while keeping its current corporate database. The platform manages connection pooling and can cache the results of supported queries, avoiding the need to open a new geographically distant connection for every request.

Durable Objects for Stateful and Real-Time Applications

Ordinary Workers are stateless: two consecutive requests may be executed by different instances and must not depend on memory left behind by a previous request. Durable Objects introduce a form of stateful computing.

A Durable Object is a special type of Worker with a global identity and private, transactional, strongly consistent storage. Requests targeting the same object are coordinated through a single instance. New classes can use a SQLite database directly attached to the object, keeping computation and data close together.

This model is suitable for chat applications, collaborative documents, real-time notifications, shared sessions, and multiplayer games. Durable Objects can act as WebSocket endpoints and coordinate thousands of connections. With the WebSocket Hibernation API, the object can leave memory during periods of inactivity without disconnecting clients and reactivate when a new message arrives.

Cloudflare Containers for Complete Software and Runtimes

Cloudflare Containers makes it possible to run Docker images inside Linux virtual machines. Images can be managed in the Cloudflare registry or sourced from Docker Hub, Amazon ECR, and Google Artifact Registry.

Containers extend the available use cases beyond the natural limits of the Workers runtime. They can run applications written in other languages, software with system-level dependencies, workloads requiring more memory or CPU, and components that could not run, or would run inefficiently, inside a V8 isolate.

Every public request first reaches a Worker, which selects the Container and can act as a proxy or load balancer. The Container is managed through a Durable Object responsible for identity, routing, lifecycle, and persistent state associated with the instance.

The Container’s local disk is ephemeral: when the instance is stopped and restarted, it starts again from the filesystem defined in the image. Data that must persist must be explicitly stored in the Durable Object’s SQLite storage, in R2, or in an external database.

There is also an important networking limitation. End users cannot directly open non-HTTP TCP or UDP connections to a Container. For this reason, the platform is currently not suitable for conventionally exposing an SMTP, IMAP, or POP3 mail server, which requires public TCP connections on specific ports.

Building Infrastructure by Composing Cloudflare Services

An application can use Workers for APIs and application logic, R2 for files, D1 for relational data, Durable Objects for real-time interactions, Hyperdrive for connecting to existing databases, and Containers for components requiring a complete Linux environment.

This composition makes it possible to create a virtual infrastructure managed through code and configuration. Architectural decisions do not disappear, but fewer activities need to be dedicated to servers, patches, clusters, and traditional load balancers.

Static File Hosting and Next.js Applications

Publishing Static Files with Workers Static Assets

Workers can distribute HTML, CSS, JavaScript, images, and other static files directly through the Cloudflare network. Static content can coexist with dynamic logic within the same project: the platform serves files when they exist and invokes the Worker when the request requires processing.

This model is suitable for corporate websites, documentation, portals, and frontend applications that only require a limited number of dynamic APIs. It makes it possible to manage a single deployment without maintaining the static website and serverless backend separately.

Running Next.js on Cloudflare Workers

Next.js applications can be deployed to Workers through the OpenNext adapter. Server-side rendering, static generation, Incremental Static Regeneration, Server Actions, and other commonly used features in modern Next.js projects are supported.

Before migrating, however, it is advisable to verify the compatibility of the Node.js libraries used by the project. An application designed around a traditional Node server may require adaptations, particularly when it uses native modules or accesses the filesystem directly.

When to Use Workers for the Website and When for the Backend

For a primarily informational website, static files and a few dynamic functions may be enough. For an authenticated portal, Workers can manage APIs and authorization. In more complex systems, Workers can become the entry point coordinating multiple specialized services.

The choice therefore does not have to be between a static website and a complete application: the platform allows an intermediate solution to be adopted and the dynamic component to be increased gradually over time.

Advantages of Cloudflare Workers

Low Costs and Automatic Scalability

The usage-based model makes it possible to start with very low costs and pay according to actual consumption. There is no need to maintain oversized servers to absorb occasional traffic spikes, and the platform automatically increases the available capacity.

Lower Latency for Geographically Distributed Users

Running part of the application logic close to users reduces response times and creates a more consistent experience across different geographic regions. The benefit is particularly relevant for international applications and frequently called APIs.

Infrastructure Managed by a Global Network Provider

Cloudflare operates one of the world’s largest networks. Using Workers means relying on the same infrastructure that provides connectivity, security, DDoS protection, and content distribution services, without having to build that infrastructure internally.

Fast Deployments and Consistent Environments

Code and configuration can be versioned and deployed together. This makes environments easier to reproduce, releases easier to automate, and differences between manually maintained configurations easier to reduce.

An Integrated Ecosystem

Compute, databases, storage, real-time services, and containers share the same configuration and security model. For an IT team, this can reduce the number of platforms that need to be integrated and the number of credentials that need to be managed.

Disadvantages and Aspects to Consider

Initial Learning Curve

Workers requires a different way of thinking compared with a traditional server. The team needs to understand isolates, bindings, execution limits, distributed services, and the characteristics of the different persistence systems. The operational advantages come after an initial phase of learning and architectural design.

Incomplete Node.js Compatibility

Many Node.js APIs are available, but Workers is not a complete Node process. Native dependencies, persistent filesystem access, and some libraries designed for traditional servers may not be compatible. Containers provide an alternative, but introduce a different operational model and different costs.

Vendor Lock-In and Code Portability

Application code based on Web standards can be partially portable. Bindings, Durable Objects, D1, and platform-specific configurations, however, are proprietary integrations. If the company decided to change provider in the future, part of the infrastructure and code would need to be rewritten.

Limits to Understand Before Designing the Architecture

Each service has limits related to size, concurrency, CPU, memory, or execution duration. These are not necessarily a problem, but they must be included in the initial analysis. Designing without taking them into account can make later changes more expensive.

Cloudflare Workers vs AWS Lambda

Edge Network vs Cloud Regions

AWS Lambda normally executes functions in the selected AWS region. Cloudflare Workers, on the other hand, is designed to distribute code across the edge network. Workers therefore tends to be particularly interesting when global latency is a priority, while Lambda is a natural choice for applications already deeply integrated with regional AWS services.

Execution Model and Startup Times

Workers uses lightweight V8 isolates, while Lambda starts more complete execution environments. The Workers model favors fast startup times and widespread distribution, while Lambda offers greater flexibility in terms of runtimes, dependencies, and workloads requiring a more traditional server environment.

Costs, Scalability, and Ecosystem

Both platforms use serverless models and scale automatically, but pricing and billing units differ. The comparison should include not only the cost of the function itself, but also traffic, databases, storage, observability, and the skills already available within the company.

When to Choose Workers and When to Choose Lambda

Workers is a compelling choice for distributed applications, low-latency APIs, logic executed close to the user, and projects using the Cloudflare ecosystem. Lambda often remains preferable when the project depends on numerous AWS services, requires runtimes unsuitable for Workers, or must operate within a specific region.

When Does It Make Sense to Use Cloudflare Workers in a Business?

Companies with Distributed Users or Offices

Edge distribution provides the greatest value when customers, employees, or partners access the application from different geographic regions. For exclusively local services, the latency advantage may be less significant, although the operational benefits of serverless computing still remain.

APIs and Services Requiring Low Latency

Gateways, authentication, personalization, e-commerce, SaaS applications, and real-time functionality are natural candidates. Workers can also protect and accelerate an existing infrastructure without replacing it entirely.

Progressive Modernization of Existing Applications

A gradual migration reduces risk. A company can begin with a single endpoint, a security function, or a new application area, measure results and costs, and expand adoption later.

Projects Where Workers Is Not the Ideal Choice

Applications tightly coupled to specific operating systems, software requiring public TCP or UDP connections, highly compute-intensive workloads, or projects entirely dependent on another cloud platform may require different solutions. In these cases, Workers can still act as a gateway, but does not necessarily need to become the entire infrastructure.

Conclusion: Is Cloudflare Workers Suitable for Your Infrastructure?

Cloudflare Workers provides an interesting combination of edge computing, low costs, automatic scalability, and integration with managed services. It can support anything from a small function in front of a website to a complete application composed of databases, storage, real-time components, and containers.

The decision should take into account user distribution, team expertise, existing dependencies, portability requirements, and the limits of each individual service. For many companies, the most effective path is not to move everything to Workers immediately, but to introduce it where latency, automation, and reduced infrastructure management provide a measurable advantage.

With a well-designed architecture, Workers can become the connective tissue of a modern digital platform. Operational simplicity does not eliminate architecture: it allows teams to focus more on application requirements and less on server maintenance.