Cloudflare Workers
Cloudflare Workers gives developers the power to deploy serverless code instantly to Cloudflare’s global network.
Cloudflare Workers significantly differs from other serverless computing providers in its execution model and architecture.
A single Worker project can have logic as complex or as simple as the developer desires. A project of smaller scale might look like a Worker that returns a small HTML page on a single route. A more complex Worker project would span multiple domains, multiple routes for each domain, and different logic for each route. The developer decides the architectural complexity of their Worker project.
Your application can be made up of multiple Workers that work together and deliver a single experience to end users. Workers can also integrate with other Cloudflare Developer Platform functionality such as storage, media and AI. You will learn more about this in the Developer Platform module.
The Workers runtime ↗ is designed to be JavaScript-standards compliant and web-interoperable. The Workers runtime uses the V8 engine — the same engine used by Chromium and Node.js, and has an open-source version, workerd ↗.
The Cloudflare Workers runtime runs in every data center of Cloudflare’s global network of over 300 cities ↗. Every Worker run within its own isolate. Isolate architecture is what makes Workers efficient.
Workers uses isolates: lightweight contexts that provide your code with variables it can access and a safe environment to be executed within. You could even consider an isolate a sandbox for your function to run in.
A single instance of the runtime can run hundreds or thousands of isolates, seamlessly switching between them. Each isolate’s memory is completely isolated, so each piece of code is protected from other untrusted or user-written code on the runtime. Isolates are also designed to start very quickly. Instead of creating a virtual machine for each function, an isolate is created within an existing environment. This model eliminates the cold starts of the virtual machine model.
Unlike other serverless providers which use containerized processes ↗ each running an instance of a language runtime, Workers pays the overhead of a JavaScript runtime once on the start of a container. Workers processes are able to run essentially limitless scripts with almost no individual overhead. Any given isolate can start around a hundred times faster than a Node process on a container or virtual machine. Notably, on startup isolates consume an order of magnitude less memory.
Most Workers are a variation on the default Workers flow:
export default { async fetch(request, env, ctx) { return new Response('Hello World!'); },};export default { async fetch(request, env, ctx): Promise<Response> { return new Response('Hello World!'); },} satisfies ExportedHandler<Env>;For Workers written in ES modules syntax, when a request to your *.workers.dev subdomain or to your Cloudflare-managed domain is received by any of Cloudflare’s data centers, the request invokes the fetch() handler defined in your Worker code with the given request. You can respond to the request by returning a Response object.
By reading this page, you have learned:
- The basics of how Worker projects are organized.
- The fundamentals of how Workers execute on the Cloudflare network.
- How the request to response flow executes.
In the next module, you build and deploy your first Worker to the Cloudflare global network.
- Cloud computing without containers ↗ - A blog post detailing the containers versus isolates difference in the context of Cloudflare.
- How Workers works - Learn the difference between the Workers runtime versus traditional browsers and Node.js.
- How the cache works - Learn how Workers interacts with the Cloudflare cache.
To improve this learning path or report any missing or incorrect information, file an issue on GitHub ↗.
Connect with the Cloudflare Developer Platform community on Discord ↗ to ask questions, share what you are building, and discuss the platform with other developers.