There's some issues but it's relatively stable now.
There's some issues but it's relatively stable now.
MProbally $35 at the most (which is not nearly enough)
MOne of the team members is being really stubborn about moving to UE5, as he says the new ui messes with his workflows/mussle memory
IOof 
IYeah... I actually prefer the new UI but it's subjective I guess?
B4 million write requests is only $12 for the initial build but yeah, that's a very small budget.
MAlso he complains that performance is crap in areas now, but maybe thats because he placed 40 lights in a very small area, and they are all dynamic now instead of baked. ARGH
MI love it too
MLet me see if I can find that screenshot of the monstrosity
IAre you targeting devices with an RTX 3000 GPU or greater?
IIf not you'll want to turn off Lumen, it's a major impact if you don't have the Tensor cores.
IAlso: Unreal Engine
MAgain, team with no budget
BUncached reads would be $2.16 per user assuming each user is doing uncached 100k / hour reads for 8 hours straight for 20 days of the month.
BI could be wrong but operationally that fits within the budget
B5 devs = $10.16 in reads per month
MActually, thats not as bad as I thought
MBut its the writes that will be killer
BI didn't get a write rate per user
BIt might not be that bad
IAlso DDC is peculiar in that if you don't have too many changes to the assets then there won't be as many writes.
ISo might be reasonable depending on workflow?
MProblem with calculating write cost, is it not very consistent at all
MI am gonna have to think on this for a bit
BPlease check my math
$12 for a one-time cost for the initial build
$1.35 / mo for storage assuming you're storing 100 GB for the month.
$10.16 / mo for class B for 5 users assuming each is doing 100k reads per hour, 8 hours a day for 20 work days per month
$0/mo for class A for 5 users assuming each is doing 1k writes per hour, 8 hours a day for 20 work days per month.
$12 for a one-time cost for the initial build
$1.35 / mo for storage assuming you're storing 100 GB for the month.
$10.16 / mo for class B for 5 users assuming each is doing 100k reads per hour, 8 hours a day for 20 work days per month
$0/mo for class A for 5 users assuming each is doing 1k writes per hour, 8 hours a day for 20 work days per month.
MActually, that looks good
MI will still need to think on it for a bit
BIf you do 10k writes/hour then it's $30 for class A
BBut 10k writes per second seems high. That's 2rps of writes per user continuously for the entire hour
MIt probally wont be that high
MAs at most we usally only have 2 users actually doing stuff at a time
BThen I think you'll likely end up with $0 / mo for writes (excluding the initial build)
MIt really depends on whats going on at the time
MAnyways, I gotta call it a night, thanks for all your help!
Bnp
Bgood luck
B@Isaac McFadyen | YYZ01 do you know who's responsible for https://pricing.ceru.dev/r2 ? I'm curious if the pricing configuration accounts for the free limits correctly and the github source doesn't seem to include R2
Estimate your next bill, see the price difference. Unofficial calculator for Cloudflare Workers Unbound, Cloudflare R2, and KV.
IIt's @toridev (Cerulean without the nickname).
FThe following features are currently on the roadmap for R2 but not yet implemented.Pre-signed URLs are now implemented!
- Public Buckets
- Mapping a bucket to your custom domain
In the meantime, you can use a Worker to replicate the vast majority of functionality such as serving & caching public assets.
Take a look at the Demo Worker example here: https://developers.cloudflare.com/r2/examples/demo-worker/
Also, there's a great community project called Render that's made for R2:
https://github.com/kotx/render
Workers will not be required for making assets publicly available in the future, they are just an interim stop-gap.
BYes. It's part of the public buckets work but it'll be one of the last things implemented.
BThe current solution indeed is to have a Worker in between that adds the CORS information you need
BIf anyone writes a unit-tested Worker that evaluates S3 CORS rules and applies them to requests (as JS objects - I can do the XML -> JS piece) that'll make that piece go 
faster 
faster 
Hrequest two function of r2
have two object:
object1/test.txt the content is “test1111”
object2/test2.txt set redirect to object1/test.txt in metadata （the object is 0 bytes file only set matedata）
Then request
https://domain/object1/test.txt
response filename test.txt with content test1111
https://domain/object2/test2.txt
response filename test2.txt with content test1111
and if bind domain2 with prefix：object2
will support use
https://domain2/test2.txt
to request /object2/test2.txt
of course it can be implement with workers but it will cost more
- support redirect object
- support bind custom domain with prefix
have two object:
object1/test.txt the content is “test1111”
object2/test2.txt set redirect to object1/test.txt in metadata （the object is 0 bytes file only set matedata）
Then request
https://domain/object1/test.txt
response filename test.txt with content test1111
https://domain/object2/test2.txt
response filename test2.txt with content test1111
and if bind domain2 with prefix：object2
will support use
https://domain2/test2.txt
to request /object2/test2.txt
of course it can be implement with workers but it will cost more
�?r2-roadmap
FThe following features are currently on the roadmap for R2 but not yet implemented.Pre-signed URLs are now implemented!
- Public Buckets
- Mapping a bucket to your custom domain
In the meantime, you can use a Worker to replicate the vast majority of functionality such as serving & caching public assets.
Take a look at the Demo Worker example here: https://developers.cloudflare.com/r2/examples/demo-worker/
Also, there's a great community project called Render that's made for R2:
https://github.com/kotx/render
Workers will not be required for making assets publicly available in the future, they are just an interim stop-gap.
BI'm aware of the request for symlink or redirect support (this is the 3rd time you're asking). Seems unlikely we'll implement it in any short term. There are several challenges.
- That operation doesn't exist at all in S3 which means what does the shape of the REST query look like in a way that remains future-proofed against conflicting with future changes AWS makes?
- This operation doesn't exist at all which means how do you make it accessible from tooling?
- What is the expectation around behavior if the original file is deleted?
- It complicates the metadata layer a bit.
CopyObject as a custom copy directive (we have REPLACE so probably SYMLINK might work there). That solves 1 and 2 but makes 3 weird since after issuing a CopyObject to create object2/test2.txt --> object1/test.txt, DeleteObject object1/test.txt, the copy "doesn't exist" and is dangling metadata that you'd be billed for that's difficult to cleanup (you'd have to basically try to access that object or encounter it in a list). What happens if you now put a new object1/test.txt - is the symlink expected to work? The solution here is probably that such a redirect shows up in
ListObjectbut always returns a 404 on a GET (but does it respond to a HEAD request? maybe only if there's an option that says "don't resolve symlinks"?)
PutObjectobject1/test.txtCopyObjectobject2/test2.txt --> object1/test.txtCopyObjectobject1/test.txt --> object2/test2.txt
This isn't even getting into the concept of making cross-bucket symlinks.
