If you even remotely think about cloud architecture then you have defintely heard of CloudFlare. But have you heard of CloudFlare Workers? Maybe you can say "yes" as you remember reading a headline here or there since their release in 2018. Or, perhaps, like the ever growing list of services in every other cloud dashboard (I am looking at you AWS) you just never got around to learning about them. If you aren't lucky to already be familiar with Cloudflare workers then keep reading on. Heck, if you are familiar with CloudFlare workers maybe keep reading anyway for a different perspective.
What are CloudFlare Workers?
A CloudFlare Worker is the tip-of-the-spear in CloudFlare's compute offerings. It's the foundation for pages and their functions, the gateway for containers, and an incredibly powerful way to run code on CloudFlare's edge for next to nothing in costs. Here are the key things to note:
- They are V8 Isolates using the workerd runtime
- Support for modern JavaScript and TypeScript and a select few other languages
- no cold starts (near 0ms startup latency)
- Deployed to CloudFlare's edge network
- Tight integration with other CloudFlare services, such as storage and other compute services.
- Cheap, cheap, cheap
Here are some the possibilites with CloudFlare workers:
- Static or minimally dynamic websites
- Full stack applications built on frameworks designed to run within CloudFlare Workers
- Microservices
What are Cloudflare Containers?
CloudFlare Containers (in Beta as of 2026) allow you to host your own containers which you can build and push to CloudFlare. This means you can host just about anything you want on on CloudFlare. Anything that doesn't run on a CloudFlare Worker can be ran on CloudFlare Container and accessed from a CloudFlare Worker. Here are some of the possibilities with CloudFlare Containers:
- Full-stack applications such as Laravel, Symfony, or Ruby On Rails
- Pre-built services bundled with Docker and meant to augment your worker application
- Augmenting legacy services that can be containerized
Now here's what makes CloudFlare containers different than traditional container hosting. Containers are built ontop of and stored as "Durable Objects" that are attached to a CloudFlare worker. That means they aren't public facing and can't be directly accessed by a host. All requests to your containers must be routed through a worker. A bire more on this later.
Other Benefits
Automatic Deployments with Github
You don't even need to setup a CD pipeline to deploy your worker. You just need to install the CloudFlare app into your Github account, grant access to the target repo(s), and set that repo on your worker. Every time you push to the target branch it will automatically deploy to your worker.
Containers still require a traditional CD pipeline. For this, you can use a Github Action to compile the container and deploy both the container and worker in a single location.
No CDN or DNS to manage
Worker builds can publish their static assets directly to CloudFlare's CDN. This avoids serving those static assets from the worker and saves on worker requests.
Hook your workers to domains and let CloudFlare create and manage the DNS records. Since this is CloudFlare of course that means everything automatically sits behind CloudFlare's CDN and suite of other services. SSL is automatic. WAF deployed with the click of a button. So on and so on.
Integration with other services
Here is a curated list of other Compute and Storage services you can easily interface with from within a worker and/or container:
| Service | Description |
|---|---|
| R2 | S3-compatible object storage |
| KV | Simple Key-Value storage |
| D1 | SQLite Databases |
| Queues | Managed queues |
| Browser Run | Headless browser service |
| Email Sending | Outbound e-mail |
| Email Routing | Inbound e-mail |
| Observability | Logs |
Live tests
To stay true with my show-me state roots, let me show you several examples with live runners. Each runner is a separate worker and Github repo. The runner-only workers are deployed automatically by Github triggers. The container workers are built by and deployed from Github Actions. All workers are backed by the same Supabase instance.
| Language / Framework | Worker | Container | Database | URL | Cold Start | First load w/ SQL query | Second load w/ SQL query |
|---|---|---|---|---|---|---|---|
| VanillaJS | Yes | No | Supabase | https://vanillajs.cloudflare-worker.delamatre.com/ | <5ms | ||
| Hono | Yes | No | Supabase | https://hono.cloudflare-worker.delamatre.com/ | <5ms | ||
| Laravel on FrankenPHP | Yes | Yes | Supabase | https://laravel.cloudflare-worker.delamatre.com/ | |||
| Laravel w/ Octane on FrankenPHP | Yes | Yes | Supabase | https://laravel-octane.cloudflare-worker.delamatre.com/ | |||
| Ruby on Rails | Yes | Yes | TBD | https://rails.cloudflare-worker.delamatre.com/ |
An interesting note is that you could run all of the above on a single worker. Bring a mix of vanilla JS and/or framework. Route part of your app to Laravel. Route another part to Ruby on Rails.
Pricing
Did I mention it's cheap? I guess cheap is relative, but with CloudFlare Workers you could host potentially hundreds of small and medium sized websites with relatively high volume before incurring any costs. If you want to use CloudFlare containers you will need to move up to a paid worker plan but that starts at only $5/month. Let's take a look at worker pricing (6/9/2026):
| Plan | Requests | Duration | CPU time |
|---|---|---|---|
| Free | 100,000 per day | No charge for duration | 10ms of CPU time per invocation |
| Standard | 10M included/month + $0.30 per additional million | No charge or limit for duration | 30M CPU ms included/month + $0.02 per additional million CPU ms |
Max of 5 minutes of CPU time per invocation (default: 30 seconds)
*Max of 15 minutes of CPU time per Cron Trigger or Queue Consumer invocation
It's worth noting that Workers are billed on CPU time rather than execution time. If your application spends most of its time waiting on a database or external API, your bill may be significantly lower than you would expect from traditional serverless platforms. For example, this website uses roughly 6000ms of CPU exectuion time per 10,000 worker runs. With between 1 and 4 worker runs per pageload (html page + API calls). That means at 250,000 monthly page views I would use well under 1,000,000 requests and around 600,000ms CPU execution time. That's literally pennies per month if I reached that level of traffic.
Gotchas
CloudFlare workers and containers can replace a decent portion of your traditional hosting infrastructure. But it's still lagging in a few ways for now.
Databases, Databases, Databases
Here are your options for running a database:
- D1 - A SQLLite database service from CloudFlare
- Host your own - Setup your database on a third-party (Neon, Supabase, RDS, etc.) and connect to it from your worker and/or container
- Hyperdrive - Host your own database (see above) and connect to it through Hyperdrive. This option doesn't work for CloudFlare Containers.
- Container - I guess you could technically host a database on a CloudFlare container, but it's not recommended. D1 would be a better option for ephemeral databases.
What's notably missing is a MySQL or Postgres offering from CloudFlare. This means that you either need to architect around this limitation or you need to bring your own. Using HyperDrive can help reduce some of the overhead of bringing your own database but it's limited to use directly on the worker (i.e. not a container). The moment you bring in a MySQL or Postgres database the latency starts to edge your application towards that of a traditional application, especially if you are using a container.
Containers must be accessed through a worker
I already mentioned this above but it bears repeating. Containers are built on and stored as "durable objects" that are attached to your worker. In this way the worker acts as a sort of router that you can fully customize. This opens some interesting possibilities but also has some drawbacks. Containers, unlike workers, are hosted in a single region and must have traffic routed to them by the worker. This adds latency compared to a worker-only deployment. It also means you can't route traffic directly to a container and so it's not a replacement for traditional container deployments.
On the other hand letting the worker handle routing gives you the ability to route parts of your site differently. You could route traffic between multiple containers allowing you to build-out a multi-service app. You could also setup default routes which route traffic to a traditional application on your container and then augment this with new routes served directly by workers. Both options could be interesting for hybrid deployments, including slowly moving functionality out of a legacy app into a more performant worker. As for performance, if you were already considering proxying traffic through CloudFlare than sending it through a worker shouldn't be a deal breaker.
Stateless
Your application must be designed to run stateless. You do have options for locally attached storage on durable objects but they are ephemerel. This could be a deal-killer for legacy applications like WordPress that were designed with a stateful hosting environment in mind.
What's next?
This largely depends on your use case. Are you hosting a (mostly) static website, building out a greenfield service, or need absolute peak performance? You should probably lean into building out a solution entirely on CloudFlare Workers. On the other hand if you need a traditional full-stack application, a backend service that doesn't run within a worker, or are porting a legacy app than you need to also look at CloudFlare Containers.
CloudFlare Worker only
- Choose either VanillaJS or from a number of frameworks designed to run on a CloudFlare Worker:
- Hono
- Astro
CloudFlare Containers
@todo
Conclusion
CloudFlare's offerings in Compute and Storage services are a compelling story that you should evaluate the next time you are considering your cloud architecture. For my own personal projects I have moved completely off of AWS and only need to maintain a small (free) database at Supabase. I think that's probably true for many small to medium-sized websites and especially those that are essentially static.
With CloudFlare's already enormous penetration in the enterprise market it also makes a compelling case for more advanced use cases. It's entirely possible that you could build out new services or augment legacy services with little pushback if you already use CloudFlare. It's also enables a path for many to architect new solutions completely within the CloudFlare ecosystem and may lead some to ponder...do I even need AWS?