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.
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.