Cors Headers on R2 Storage

Hi all,

Have had a look around the forums and cannot find what I am after.

Basically using Laravel+Livewire, have the typical CORS preflight related headache when trying to use R2 Storage.
Managed to get around that with AWS as they allow bucket policies to be applied, be damned if I can find the same on R2, did read that this can be sorted by using a Worker, have absolutely no idea how to implement that, anyone have a hint on this? Not asking for people to do it for me.



There is an example worker in the documentation.

1 Like


Thanks for the reply, sadly not what I was looking for, I wrote my own api on that interacts with the R2 system and can push files from the server to it without having to use a Worker etc.
That works fine, my issue is when using something like Livewire where it can write uploads directly but hits the CORS preflight stuff, of course I can save use uploads to the server then push them to R2 but I am trying to eliminate files even touching my app server, I was expecting a Worker to somehow sit between my app server and the R2 system to take care of CORS, I just have no idea where to look at that.
Also seems a little on the OTT side to have to fire a worker up to interface with R2 when it can simply be done via a policy on AWS (not that I intend on using anything Amazon for what its worth)


Same here, CORS issue on presign is a blocker for me. I really really don’t want to have to use s3.

Not sure how I got tagged here haha - but I’m not aware of any timelines, or what it’ll look like.

I probably know as much as everyone else in this thread, I’m just a member of the community. The R2 team are very active in the Cloudflare Developers Discord, so you can likely get a quicker answer in there. Cloudflare Developers

It might end up being a CORS configuration (like S3) that you can apply to a bucket, it might only be possible by adding a custom domain onto your bucket and using Transform Rules, or it might be any variation of the two when it first launches with more ergonomic approaches following in the future.

Using a Worker is simply a very powerful interim solution - you can do your own authentication, rate limiting, access control lists, caching and whatever else. That doesn’t mean that it’ll all be gated behind a Worker as some sneaky scheme to charge you more money, it’s just that it provides the value now so that important things like public buckets & performance improvements can take priority.

I expect public buckets to be landing very soon, and CORS configurability will probably be a fast-follow if not launched at the same time. That’s just my thoughts, they may be completely wrong.

This is really a necessary feature for me aswell!
Is there any timeframe when this is implemented?

Have made some very valid points there!

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.