I think some here will say "why not just use Cloudflare directly", but I disagree, I think this plugin makes sense. Cloudflare is relatively straightforward for technical users, but many Wordpress users are non-technical. $2.99 is a very small amount for reliable fast images, while also packing a pretty nice margin for you for most users who will need a tiny fraction of that.
And I agree, if a site is behind Cloudflare DNS this plugin does not make much sense, but it's a solution for many non-technical users, as you mentioned.
I'm sorry to say that with this plugin, you're just adding to the pervasive tracking enabled by widespread use of Cloudflare.
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.
> Bandwidth Saver respects your privacy and your visitors’ privacy: Does not track visitors...Does not collect analytics
Wouldn't this cause a site's visitors to send traffic to cloudflare in situations where they wouldn't otherwise, allowing cloudflare to log their IP, timestamp, and the image requested, along with any other data in the request header? If this plugin wasn't used on the site cloudflare wouldn't get/log/track any of that. I'm not sure that handing all that data over to a third party (especially one as large and centralized as cloudflare) is compatible with respecting visitor's privacy. At the very least, site owners should be made aware of the fact that this is data will end up being shared.
"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"
Bandwidth Saver respects your privacy and your visitors’ privacy:
Does not track visitors
Does not use cookies
Does not collect analytics
Does not phone homeBecause all that tracking and data collection will be done by Cloudflare (a company subject to the CLOUD act) instead.
I wrote a basic plugin for Jekyll to automatically prefix my images with this. Pretty much just set it and forget it: https://github.com/catskull/catskull.github.io/blob/master/_...
Am I missing something or is this way harder to do in Wordpress?
have a squid proxy on a $5 unmetered vps, referring to WP as a content-origin and then just use this to rewrite the image URL without using cloudflare at all?
(also possible with an apache directive but , doing it in WP could be useful)
and could you not .. just do the same for your $2.99 customers so you dont get a surprise $2000 bill or find yourself told by cloudflare that its time to pay up?
although if youre allowing uploads youre not in control of youd really need something like sightengine (or to roll your own) sooner or later to make sure no CSAM uploads and then theyll just get you in fees that way.
otherwise one person who does that might get your account canned and take every single blog using this service out
thats why id be a proponent of steering them to sign up and use their own CF R2 bucket , or self hosted minio (s3), or other s3 provider… or the squid thing for technical users who dont like cloudflare and its ilk. then theyre responsible for what they upload and host.
most wordpress static site plugins will configure the s3 hosting.
i just am not familiar with any that would easily let me plug in my own base URL for images. they probably exist… and if not then good job for tackling it. at the moment im going about this a different way and it works? but i wouldnt know how to go about packaging and shipping this up in a way thats accessible for everyone.
maybe a crude squid.conf generator you put your real wp url and your new cdn url into. but then youll want https on it too
i do know a lot of people would love to have “cdn” features without taxing the i/o and bandwidth on wordpress but who ALSO dont want to get cloudflare into their hosting for one reason or another. (im not there yet but i get it.)
the hug of death on stock wordpress is real which is why im already doing this in practice. with extra steps. (specifically a cloudflare rewrite rule for /wp-uploads/* to the alternate base URL which could also be done in vhost directives)
imo WP needs a third option under site URL and admin URL , for the base image URL.
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.
i think thats the first tack i took.
but then just using wordpress itself as the origin server made the fetch and availability immediate.
and then yeah if youre accomplishing that thing,and filling that gap in. that would be useful and i might give it a try!
ive gone about doing this, in effect, about five or six different ways and youre on the right track for something useful that, no, nobodys (exactly) offering yet. unless you want to go all static which begets other problems like no native comment functionality.
or, use an existing “static website generator” solely to mirror your wp-uploads on publication but then not actually use a static site ;)
youre pitching an in-between for the media. and there is one other plugin that will optimize cloudflare but there was some reason i rejected it. ( i think it irreparably broke the entire site on being disabled or uninstalled so if cloudflare was down and you wanted to just point DNS at your naked IP. you were going to be restoring your database.)
it would be super nice to be able to turn this on/off at will- as others have asked “what if cloudflare is down” , or what if your account gets sanctioned by CF—
well there you go, disable this plugin for an immediate workaround . no need to log into cloudflare or a linux shell to kill or edit my rewrite rules if i can just disable a plugin from the convenience of the wp-admin UI.
you already clarified that all the content is safe and intact locally!
i am not aware of other plugins that would make that part this easy.
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.
But technically would it be better to have the plugin to any transformation and then have just cloudflare in front of the website raking care of all caching ? (I thought they even provide a WordPress plugin for that).
Also careful with hosting other people content under your domain/service under your name especially with CSAM stuff and other illegal material that your domain becomes the face of.
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.
I've wanted to explore R2 (I use S3/Cloudfront today) and this looks like a great way to do so!
It’s possible that group doesn’t exist.
Where does the url rewrite happen - wp hook or in cf worker?
As another comment said, 2.99 unlimited is a TERRIBLE idea
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?
It also seems like you're recreating or even bypassing existing mechanisms
* why do the processing in wordpress first rather than just offload it completely to cloudflare's image optimization service? I don't think you even need the worker for that - it can be done automatically in various ways.
* are you deleting the files from the server after offloading? That's largely the point of such wp offload media plugins, some of which support r2.
My point about pricing was don't offer flat fee.
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.
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.
We also have our own CDN-ish DigitalOcean droplets with Terabytes of data transfer available (stacked droplets increase the TB limit under the same account, too). This is a $10-$15 solution for 100+ WordPress sites.
Small droplets (DigitalOcean, Vultr, or managed like CloudWays) offer multi-TB bandwidth for data transfers. With the WebP format, even the highest-resolution image is under 100 KB. We try to keep everything under 50 KB for mobile optimization as well. I don't see sites using 50 GB per month and always below the limits. Why would anyone need an extra layer of complication?
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.
Cloudflare's pricing is "free until you get a message from the sales team that it's time to pay up". That's impossible to compare to anything else, so yes effectively a different market segment.
I’ll stick with my $20 subscription, thanks.
Having said that, I am a big fan of CDNs. Your origin server can generate pages and that’s a lot better than static sites.
If you want a decentralized Internet, don’t use the Web. Use something like Pears / Holepunch / Hypercore / Dat (same thing hehe)