Cloudflare is almost perfect

A photo of myself sat on the green cliffs of Cornwall in the UK with the ocean & sky in the background.

If you’re building a platform or product nowadays, as a developer in some way or another Cloudflare may fit into your stack. Whether that be from just using their network for DDoS protection, using R2 for cheaper object storage, or even going all in on using their Workers product for serverless compute.

However, having poked around with Cloudflare for a while now, there are a few things that I think are missing from their platform that would make it a perfect platform for developers.

So, since we’re close to the end of the year I thought I may as well make a little wish list of things I’d like to see from Cloudflare in 2025.

Containers

Starting off with my biggest ask: Containers, containers and more containers!

I used to be a big fan of serverless computing or lambdas, and I still think they have their place. But I have seen too many horror stories of insane bills & issues myself of having to work around their limitations that if I was to build a product today I would not even bother with serverless lambdas at all and instead containerize everything.

With a container pretty much all the common problems go out the window, especially those stupid cold start issues.

The problem right now though is most other container-as-a-service products are either too expensive or too limited in functionality. Google Cloud Run is the closest to what I would want, but it is both too expensive to run and also locks you into the Google Cloud ecosystem which is both complex and expensive in every other way.

Now, Cloudflare did already announce earlier this year that they are already working on their own container-as-a-service product, and is apparently already in use in a number of other Cloudflare products. So I am really looking forward to seeing this product come out of closed alpha/beta and into general availability for everyone to use.

But with that said, I want to emphasize a few key features I really hope Cloudflare considers:

  • Global deployments: Workers are already deployed globally to multiple regions, let containers do the same. Let me just check a box to add a region & leave Cloudflare to handle the networking and geo-routing.
  • Minimum scale count: 🖕 cold starts. Let me just set a minimum container / pod count so I can have at least 1 container always running.
  • Sidecar containers: Google Cloud Run has a cool feature where you can run multiple containers next to each other. So for example, if you want to run Caddy or Traefik as a reverse proxy for your ingress container and then have both your web frontend container & backend api container co-located in the same service, you can do that & have everything be super low latency.
  • Image registry: Offer a 1st party image registry & make it easy to use. If not, make supporting the GitHub Container Registry the go-to. For me I don’t want to bother with Docker Hub when GitHub Container Registry does everything I need.
  • S3 volume mounts: Another cool feature Google Cloud Run offers is you can access a Google Cloud Storage (S3) bucket via file-system rather than over the network.

Workers HTTP imports

A while ago I made this post on Bluesky about how if you want to quickly deploy a web application, whether that be a RESTful API or a server-side rendered application, Deno Deploy with Hono is an absolutely killer combination. Especially since you can do it all via a web based editor.

Being able to do something similar to this with Cloudflare Workers would be amazing. However right now there is one big blocker, besides TypeScript support, and that is that there is no native support for HTTP imports.

Imagine to create a super basic RESTful API all you needed to do was go to the Cloudflare dashboard, go to the workers page, click “Create” & then paste in the following code:

_worker.js
import { Hono } from 'https://esm.sh/[email protected]';
 
const app = new Hono();
app.get('/', (c) => c.text('Hello World!'));
 
export default {
	fetch: (request, env, ctx) => app.fetch(request, env, ctx),
};

No more need to set up a new Node.js project, repository to store it all, connect the repo to a CI/CD pipeline, etc. Just write the code and deploy it using your favourite packages via HTTP imports.

R2 feature compatibility

R2 is amazing! Plain and simple object storage. You just give it data to store and that’s it.

But that being said, there is a few small missing features that I really hope get added:

  • Encryption: For the rare use case it would be handy to be able to securely store data at rest, kind of like how Google Cloud Storage does it.
  • Revision history: Being able to see the history of a file and restore it to a previous version. This would be super helpful for infrastructure as code files like Terraform state files.
  • S3 client: @aws-sdk/client-s3 sucks, both in terms of DX & package size. I wish Cloudflare would make their R2 worker API a general purpose package for anyone to use. The closest I have found that is good in the meantime is @bradenmacdonald/s3-lite-client.

The dashboard sucks

I’m sorry but I will put it blunt, it does suck.

It’s slow, confusing UX where products are placed sparatically, fast page loads but data loads in slowly filling the page with loading spinners & often giant red banners at the bottom telling me about some internal error when trying to load the page.

This isn’t as much of an issue if you’re using any kind of infrastructure-as-a-code system, but even then you would still need to use the dashboard to view analytics, billing, etc, and on that scenario it would be helpful if the dashboard was a bit more user friendly.

Support more TLD’s

Over the past year or so I have slowly been migrating all my domains to Cloudflare but a lot of which I have had to wait for a little bit for some missing top-level domains to be added to Cloudflare’s registrar.

Pretty much all of the essential TLD’s have been added now, but I do hope Cloudflare continues to add more, like .rs for Rust projects`, so that in future I don’t even need to consider NameCheap or some other 3rd party TLD provider and instead I can just buy and consolidate everything in one place. Not exactly a sore spot but a nice-to-have.

Sharable API key permissions

This is a small one, but I think it would be really helpful for a niche number of developers and blog writers.

In short, I wish that when you were creating a new API token in the Cloudflare dashboard that it would give you the option to copy a code, likely a hash of some kind, that you could then share around to paste in the exact permissions needed for something.

For example: Say you’re writing a blog post on how to use deploy a Cloudflare Pages site using Terraform. Terraform needs a Cloudflare API token to do this, but you don’t want to give it full access to your account. So you create a new API token with the exact permissions needed, copy the hash, and then paste it into your blog post.

Very niche but handy if there is a lot of permissions that need to be added or say permissions get changed or removed, the hash could automatically handle populating the replacement.

Analytics site permissions role

Lastly this sort of follows on from the above, but currently from my testing there is no way to create an API token that has write access for Cloudflare analytics sites so there is no way to automate the creation of new analytics sites with something like Terraform. Or if there is a permission that can do it, clearly document it instead. Currently there is a “Account Analytics” or “Analytics” permission but both seem to be read only.

And that’s it, for now anyway. I am sure over the course of the next year or so I will think of or find many other little features or fixes that Cloudflare needs to implement to finally make their platform over that line where I would use Cloudflare’s suite of products for everything I need to build a product.