cr1st1an

If you run into anything or have thoughts later on, feel free to reach out: inbox [at] cris.mx

Thanks, I appreciate that. I went ahead and updated the readme and the plugin text so the privacy section is clearer about what Cloudflare logs and what the plugin itself does or does not do. I want people to understand exactly what they’re opting into, so this feedback really helped.

Thanks for sharing all this. It is clear you have gone through several versions of solving this problem, and a lot of what you described is exactly what led me to build this plugin.

The “in-between” space you mentioned is what I am trying to make simple: keep WordPress as the origin, avoid all the static-site complexity, and still get CDN-level delivery without touching DNS.

And yes, the instant on/off switch is a big part of the design. A lot of people have been burned by setups where Cloudflare goes down or an account gets flagged and suddenly the whole site is tied to that infrastructure. Being able to disable a plugin in wp-admin and immediately fall back to local files feels like the right safety valve for most WordPress users.

I appreciate you taking the time to think it through. If you try it, I would be interested to hear where it fits (or doesn’t fit) with the approaches you have used before.

You are right that a lot of those clients are on “unlimited” hosting and never think about bandwidth at all. I am still trying to figure out how big the overlap is between “does not want to touch Cloudflare” and “actually cares about image performance.” This thread is helping me sanity check whether that overlap is real or just in my head.

That could work as a separate plugin. This one is intentionally not an offloader. WordPress keeps storage and transformations, I only rewrite the final URL.

Right. The target user is not using Cloudflare nameservers.

Noted. I agree the current wording is not clear enough about what Cloudflare logs. I am going to rewrite that section so it is more explicit.

Do they? I honestly do not know yet. That is what I am trying to learn.

Mine is a tiny nail. Please buy my plugin.

If someone can get Cloudflare caching working without changing nameservers, then yes, this plugin does not offer anything new for that case.

Yup, been there. I was serving more than 45 TB of data a month on one site, and they tried to push me into a $4,000/mo product.

I’ll stick with my $20 subscription, thanks.

Thanks for the detailed perspective. Your setup makes sense for agencies or teams that can manage their own caching, droplets, image formats, and traffic patterns. In that environment a plugin like this is not really needed.

The plugin is aimed at a different group. A lot of WordPress users are not on Cloudflare, do not want to touch DNS, and are not comfortable running their own CDN proxy or tuning image formats. They just want their existing media to load faster without changing their hosting stack.

If you are already keeping everything optimized and have a CDN pattern you like, then you are already covered. This is more for the long tail of smaller sites that will never set up their own caching rules or droplets. It is just a simpler path for them.

Thanks, that is exactly the angle I am leaning into. The whole point is to give users most of the benefits of Cloudflare without having to move nameservers or deal with caching rules or the dashboard. For people who already use Cloudflare directly, this might not be needed. For everyone else, it removes a lot of the steps that usually cause support tickets or confusion.

I agree about the positioning. I am updating the wording so it is clear that this is not trying to compete with Cloudflare’s full feature set or with full image optimization plugins. It is more of a simple “use Cloudflare as your image CDN” switch for the long tail of WordPress sites that will never touch DNS settings.

If you have thoughts on how to phrase that more clearly, I am open to ideas.

Thanks for the follow up. I think the main difference is that I am not trying to build another offloader or a full image optimization service. WordPress stays in control of storage and transformations. The plugin only rewrites the final URL so the request goes through a Worker and then Cloudflare’s edge cache. That is the entire scope.

I am not deleting anything from the server and I am not replacing the media library with R2. If someone needs real offloading, there are already plugins built for that and they make sense for bigger or more storage heavy sites.

Using Cloudflare’s native image service is also an option, but it requires Cloudflare setup inside WordPress and user credentials. The Worker avoids that and keeps the whole Cloudflare side in one place. For technical users your approach works fine. The plugin exists for people who want CDN level delivery without touching any of that.

And yes, I am moving away from the flat fee idea. I appreciate you pointing it out. If you have thoughts on what kind of limits feel reasonable for small to medium sites, I am open to it.

That’s the main question for me now: is there a subset of users who can’t or won’t switch their nameservers to Cloudflare, yet still need a lot of bandwidth?

It’s possible that group doesn’t exist.

Thanks for the detailed reply. Let me try to clear up a few things, because I think we are talking about slightly different use cases.

The plugin is not trying to replace Cloudflare, Squid, Minio, or any other origin setup. It also is not an offloader. WordPress still stores the files and keeps whatever transformation pipeline you already use. The plugin only rewrites the final image URL so the request hits a Worker that fetches the file on demand and caches it in R2. That is the entire idea.

You could absolutely build something similar with Squid or Minio or a reverse proxy. There are many valid ways to do this if you are comfortable managing the infra yourself. The plugin exists for the large group of WordPress users who are not going to set up their own proxy, or Minio, or custom rewrite rules. They just want their existing images to load faster without touching their hosting stack.

On the managed plan, you are right that I need good safeguards. I agree that self hosted R2 or self hosted S3 makes the most sense for larger or more active sites. My plan is to encourage that path when usage grows so the shared bucket does not become a liability for anyone.

The idea of WordPress having a separate “base image URL” setting would actually solve a lot of problems. Until that exists, this plugin is basically trying to fill that gap for non technical users.

If you have suggestions on how to simplify the worker pattern further, or how you would package your Squid setup so it is accessible to others, I am definitely interested in hearing more.

Right. The target user is not using Cloudflare nameservers.

Lucas, let me know if I can help with anything.

inbox [at] cris [dot] mx

Thanks for all the comments so far. I wanted to share what I am taking from the discussion and also open the door if anyone wants to keep pushing on any of these points. There is a lot of useful input here.

About the $2.99 plan. Several people pointed out that the pricing feels too low or too open ended. That is fair. I priced it that way for launch, but I am going to adjust it with a clearer fair use limit and a slightly higher base price. If anyone has strong opinions on what feels reasonable for small sites while still being safe for me, I would love to hear it.

Who the plugin is actually for. A few replies assumed this is mainly for people who already use Cloudflare DNS. The real target is the group that cannot or do not want to move their nameservers, but still want Cloudflare-level delivery. If anyone here has seen this pattern with clients or non-technical users, I am curious how common that is in your experience.

Privacy wording. Some comments pointed out that my privacy section could be clearer about what Cloudflare logs. I agree. The plugin itself does not track anything, but Cloudflare obviously logs what any CDN logs. I will rewrite that part. If there is better wording that avoids confusion, I am open to suggestions.

Why use a Worker at all. This is not an offloader, although that's a good plug in on itself. I saw a few questions about why not rely entirely on Cloudflare’s built in caching. The Worker is mainly there to keep all Cloudflare setup outside of WordPress and avoid credential handling inside the plugin. If anyone sees a simpler pattern that avoids that overhead, I would like to hear it.

Content and responsibility. The point about hosting other peoples images under my own domain is valid. I am adding more safeguards and encouraging bigger sites to self host their Worker. If you have experience dealing with this at scale, any advice is welcome.

Overall this thread has been helpful. There are still a few open questions and I am happy to keep the conversation going if anyone wants to dig deeper into pricing, edge behavior, privacy, or Cloudflare alternatives.

This is true. Honest question: how technical are your clients? I’m trying to get a sense of whether there’s a market where paying $2.99 a month is a better choice than moving the domain to Cloudflare.

Yes, the worker handles the fetch and cache. In normal use the URLs would point straight to the R2 public endpoint. Cloudflare might end up cheaper than Bunny.net. Five terabytes on Cloudflare would be about $75, but you avoid egress fees entirely and gain access to more than 300 edge locations.

The purpose of the worker is to offload all Cloudflare configuration to a single endpoint that fetches and caches each image on demand. This removes the need for any configuration at the WordPress level and keeps credentials out of WordPress entirely.

The URL rewrite happens in a WordPress hook. And yes, the $2.99 plan could technically cover around 200 GB in R2, but there is real liability attached to that.

What price would feel fair and still interesting to you?

Yes! It’s amazing. This is an option for non-technical users or anyone who can’t or won’t move their domain to Cloudflare’s DNS.

Thanks! I hope to keep it simple for a long time, and ideally profitable.

Hi, yes. Jetpack has a plugin for CDN but it's very limited I actually had the experience of having to turn off that plugin because the shared URL was reported as a malicious website, and without notice raked up a bill of over $9k for AWS bandwidth costs.

The idea here is to make it actually work at a level of service that Jetpack can't or won't. Yes, in the managed service I'll have to take that into account.

The idea here is that WordPress will still host and transform the images (could have many stacked plugins as a pipeline) but the plugin will rewrite the final image's URL to be served by Cloudflare. So you can benefit of whatever pipeline you have in the server, and let the plugin use cloudflare at the edge.

This is true, I still try to be clear about that:

"External Services

This plugin connects to external services to deliver images:

Cloudflare R2 & Workers

Purpose: Stores and serves cached images from 300+ global locations Provider: Cloudflare, Inc. Terms: cloudflare.com/terms Privacy: cloudflare.com/privacypolicy"

True true, maybe I should update it to “go outside and touch some grass.”

I'm listening.

Will do, had to make it interesting for launch :)