Hope that makes sense

If needed I can share some more details via DM

Ok. That's a bit different than what I was referring to which is cross account access for Cloudflare accounts. In this case it sounds like you have your own customers and they have accounts with you. What you would do is write a Worker to authorize the request (using whatever authorization mechanism you are using) to figure out which bucket the request has access to and then use the S3 API to upload to the right bucket. Or you could make your life even easier and use a single bucket that's bound into your worker and your authorization is at the prefix level. Unlike S3 and other providers, buckets are organizational boundaries only. Each key will have roughly independent performance of any other key (within the bucket or in a different bucket). Same kind of thing will eventually apply to things like object lifecycles. Of course you don't strictly need Workers. You could access R2 using the S3 endpoint from any server technology you want, just Workers will have the best performance and cost I think. Is that helpful?

We are still designing this component of the new website so we got plenty of room for changes; the main challenge we have is that some customers might not want us to have full control over the storage so, we have to safely store their credentials in our system; the recommended approach aws gave to us was setting up cross account access and storing the arn of the bucket and then giving the customer the identity to grant access to. Turns out that this approach works in azure and gcp but I'm unsure if it would work on cf as well

Gotcha. It sounds like you're looking for to build a SaaS product that provides a solution for each platform (ie. existing Azure Blobs, S3, and GCS customers use your product but manage buckets on the platform of their choice),. We don't yet have a good story for that use-case. I can't recall if that's on the roadmap for GA later this year. I think you'll find out more once we announce Open Beta.

> It sounds like you're looking for to build a SaaS product that provides a solution for each platform Yeah, it's a SaaS platform; normally we have always managed the storage ourselves but we have seen some "bigger" customers prefer to have control of how their files are stored. > I think you'll find out more once we announce Open Beta. Amazing :D. We only started brainstorming features so maybe we have enough room to implement r2 by the time a beta is announced

Are you also needing requester pays billing on requests?

And what kind of access are you needing to the other account?

ie. read + write restricted to one bucket, read to one bucket, or is read+write to all buckets/read to all buckets sufficient?

For some reason I can't DM you.

I have it limited to only friends, just sent you a friend request

Just access to one bucket, read and write

If you want those customers to give you access to one of their S3 buckets (or Azure/GCP equivalent), you can do that with regular API requests in a Worker..

Happy Friday everyone. As we're starting to head towards Open Beta, I just wanted to give you guys a sneak peek at the bindings we'll be publishing next week: https://gist.github.com/vlovich/9620194cd3e42a41e79d4cacbf1856ab For users already onboarded in the private beta, you'll need to publish

r2_public_beta_bindings

sometime late next week (I'm not 100% sure when we'll allow such scripts - I'll keep you updated). Please provide feedback. There's a few spots I've spotted:

R2Error

stack

is

any

instead of string (& in fact `name`/`message`/`stack` can probably be elided because of inheritance? not sure).

R2Error

code

needs a documentation note. This code is the same code that the Cloudflare V4 API that will be documented.

onlyIf

needs a documentation note. The

Headers

it accepts require HTTP header names (`IfModifiedSince`/`IfNotModifiedSince` etc).

R2Object

writeHttpMetadata

is missing a note. It writes out the headers from

httpMetadata

as you would expect (content-type, cache-control, etc) Same goes for

httpMetadata

on put (i.e.

cache-control

->

cacheControl

,

expires

->

cacheExpiry

). Note that S3 uses the HTTP "Expires" name but I think that confuses people into thinking that has something to do with lifecycle. It does not. It's simply the cache expiry metadata you associate with an object.

R2PutOptions

has

md5

and

sha1

as optionals to specify the digest of the body, but those are mutually exclusive and the type needs to be reified to reflect that (the runtime enforces this, it's just not reflected in the type system). Enjoy everyone!

We've focused on a tight core set of functionality. The S3 API has some extra features currently (e.g. copy object, multipart uploads) but we wanted to keep the canvas a bit cleaner and make sure we kept good ergonomics for the API.

This is awesome! Content length is no longer a separate required argument to

put

it seems then - woot!

No length anymore whooo

I'm building something that needs AWS S3, I'd love to try out R2, can I get access to the beta please!

?r2

R2 is still in very early access, please do not ask to be added. There is no ETA for a public beta but watch out on the blog () or follow the #892058508097388544 channel!

@User ^

You need to be careful though. The length of the

ReadableStream

must be known. For example, incoming request with a

content-length

and you're forwarding along the body. Or the response body of a fetch that has a

content-length

. Or the readable half of a

FixedLengthStream

transform stream.

That is not a helpful bot. We're going to start opening things up for our loyal Discord users in advance of Open Beta. We're just trying to smooth out some rough edges right now that aren't fun.

Makes sense! We'll stand by for the update next week about updating our test scripts 🙂

Will the API change be breaking or be in line with compat date? (For Worker binding)

Oh I just read internally that the

r2_public_beta_bindings

is a compat flag right ok, makes sense

oh it's just a compat flag? Cool okay that's easy enough to update then 😄

The public beta API and internal beta APIs are not source compatible. You will need to modify things (although hopefully simplifying at the same time). I've arbitrarily picked 4/18 as the time that

r2_public_beta_bindings

is on by default but for those that need to upgrade the compat date but keep the old bindings, you can opt to the old bindings via

r2_internal_beta_bindings

. Anyone starting should use the public beta bindings. The old ones are not as complete and have edges.

Yep seems so, makes this nice and easy

There's no "world broke please change". We learned our lesson 😉