+1!! I really need this

+1

any news on how we can make the bucket public?

Really need this to pass files to llm providers

+1 really helpful!

I created a simple template to help with this:

https://railway.com/deploy/s3proxy?referralCode=tA2R0V&utm_medium=integration&utm_source=template&utm_campaign=generic

Hi, can you help setting this up?

Also will ingress and egress fee be applicable here?

Sure, how would you like us to do that? Do you want to share your email address?

Huge +1 here.

It would be great to have a 'native' way to expose them. But one thing is very important: it should follow the Railway "no config hell" philosophy. We shouldn't have 50 toggles exposed giving us a headache every single time we deal with it.

I am for a simple "Make Public" switch that handles the safe defaults in the background, that would be the Railway way. Anyway, please add it! :)

+1 here... I'm looking for the simplest way to host images, e.g. avatars and I feel like a public bucket would be a great use case for this plus other assets were happy to expose. In most applications we have two types of buckets, public and private which helps us keen a good separation of concerns.

+1 here as well!
Trying to use it with my medusajs app for serving (product) images.
Right now the base plugin only works with public facing buckets

I found this template which does the trick for images until public buckets are working:

https://railway.com/deploy/public-bucket-image-proxy

+1 !! This would be super helpful

+1 this is pretty important

+1

+1 it's a must

+1!

I would love this. The zero egress fee from Buckets is already a huge draw for me, particularly for larger static assets (e.g. photos and videos) on my website.

Managing pre-signed URLs isn't hard but it's annoying. I would prefer to have public URLs.

+1 would love to move my GCS bucket to Railway and simply storing the public url/paths rather than having to potentially cache pre-signed for 90 days.

+1

Listen to me, man. We are out here in the digital trenches, sweating bullets, trying to pipe raw data straight into the belly of the beast—the Facebook Graph API. But your StorageAPI is stonewalling us, and it’s a goddamn tragedy.

Here’s the cold, hard, technical reality, che: we are building an automated social media distribution engine. When we kick a payload over to the Meta servers to publish an Instagram post, we don’t send them the binary image. We send them a URL. A clean, pristine, publicly accessible URL.

But your buckets? They are locked down tighter than a submarine door. They’re 100% private by default.

"Just use presigned URLs!" I hear the engineers screaming from their ivory towers. Yeah, right, boludo. We tried that. We generated beautiful, cryptographically secure 24-hour AWS SDK presigned URLs. You know what the Instagram Graph API does to them? It mangles them. It strips the query parameters. It chokes on the signature. It tries to hit the base URL, hits your default 403 Forbidden wall, and the whole operation goes up in flames.

We need the ability to configure Bucket Policies or set ACLs to public-read for specific objects/paths (like /public/*).

If we can't expose a raw, public CDN endpoint that any headless scraper, social media crawler, or Zuck-bot can GET without authentication, then your StorageAPI is useless for modern social/web integrations. It’s strictly an internal file locker.

Give us the switch. Let us open the floodgates. We know the risks, we embrace the chaos. Just give us the public-read capability before this whole architecture implodes.