But I’m happy to hear all the suggestions.

As a user of CF, I hope you folks go a lot deeper than broader. Example: Better cache management – compete with Fastly, my tickets on load balancer bugs were open for almost 6 months, etc.

most everyone is already convinced you can't run a mail server yourself, so perhaps the haters wouldn't think that cloudflare is ruining anything by getting involved in mail?

Would be awesome to have marketplace or master/sub accounts. That is, launch a saas say a landing page builder and then allow my customers to also purchase domains from my saas (under my brand account) and have them automagikally configured. Instead of having the user to use namecheap/godaddy and mess around with their crappy control panel. Maybe have an opportunity to raise the price by a $1 [to the end user] and have revenue stream?

1) Vary by cookie for $20/mo or free plans

2) A page rule for “don’t send origin cookies” or something (useful for not passing through those headers from the origin for assets/etc)

3) getting the peering connections better in AU so the network handles traffic like normal instead of only $200/mo plans getting priority/local AU routing

Global Memcached or Redis. Support caches near the edges. SPA or apps running on a client's browser/machine can use the one nearby. Support pre-populating/warm-up the caches in batch.

What Cloudflare needs is further customization, especially in regards to caching. We actually had to migrate a certain part of our infrastructure to Fastly due to the lack of caching customization/rules.

I'd like to see:

- Custom caching rules similar to the new firewall rules

- Finer granularity of the cache expiry (I'm aware Enterprise has the ability to cache for 30 seconds, but we don't want to upgrade to Enterprise just for that one thing).

- Cache hit rate analytics grouped by path/domain/etc

I’d like to be able to have more than one unique Cloudflare worker per account. And be able to assign specific workers to specific routes. This feels like an odd limitation and forces you to make huge workers code with path case statements to separate the request actions out. Pretty soon a single worker starts to feel like a large app instead of a simple function that does mostly one thing.

The ability to have more than one worker or at least a “dev” worker is really showing to be important to me. Especially the more logic that is moved to the edge, the more complex it gets, and the more testing/review might be needed so you need some way to stage changes before promoting to production.

Overall though I really like Cloudflare workers. I’ve moved a project that was built on AWS and it’s mostly all an improvement on CF, especially performance which was very noticeable. I run one public API entirely on workers and I use workers on the public facing site to scrub the path users send us and 302 them to the right place, instead of having to do that in the app. I also remove most query params inside the worker to improve caching performance. I should have a use case for the KV system soon.

While the ITP (Safari's -and maybe Chrome soon-- attempt to regulate tracking) initiative is on paper a good idea, I'm not convinced it's going to deliver.

Barging in with an OpenRTB v4 (current version is V3) that delivers on that - and maybe cut the middle men, that could be neat for every one : publishers, consummers and advertisers.