Even having read only shared volumes would really unlock some usecases. I have some applications where I need to cache packages/files and having each container be able to read from a shared volume would enable them to start much faster.

Another common use case, in lieu of having a first-party file viewer, is to be able to run a service which serves a file browser UI with another service which is actively using the volume for its function.

For example, a service for serving an HTTP API and a second service which acts as a CMS for populating the files served by the API.

Most of project deployment in railway are failed due to this missing feature. Any docker-compose project with shared volume between services is not applicable for railway.
I think this feature is one of the most important features that should have given priority.

Hi

I was reading through this thread about Shared Volumes — the ability to attach a single volume to multiple services with individual mount points — and I was wondering if this functionality is currently supported or if there are plans to add it soon?

In my case, I run several Odoo instances that all need to use the same set of custom addons, so having a shared volume would be extremely helpful. Right now, this limitation makes it hard to manage and deploy efficiently.

Any updates on this feature would be greatly appreciated!

Hello,

Unfortunately, we don't have any updates here, we are not currently planning to implement this, so I am unable to offer an ETA.

Generally, we would need to see a bigger need than 20 upvotes to implement such a large feature.

Best,

Brody

Consider me an upvote — I have a system where a user uploads a spreadsheet file and the backend dispatches jobs to a queue for workers to process the file and insert records from into the database. Having to do a huge amount of faff to move the file around for worker access that could be easily avoided with a shared volume

This is the type of feature that would allow larger projects to come to Railway. I came to test out a large production deployment that I'm considering moving from AWS, and I got stopped by the lack of shared volumes.

Simple deployments can do okay without shared volumes, but as soon as we talk about multiple containers all sharing a similar workload, this is pretty important.

I hope Railway considers adding shared volumes at some point. The platform looks promising, otherwise.

I would love to get this feature IMO this is must have for any more complicated project.

We now get 40+ upvotes, let's hope for the best.

Oh man this would be great to have. I have docker compose projects that use shared volumes. Hope this is on the roadmap now.

We’re now at 50 upvotes—clearly, shared volumes are in high demand. This feature is a must for more complex projects on Railway. Really hoping it gets prioritized soon!

Would love this feature.

I'm the 60th vote, and this will determine whether we stay using Railway, so let me explain my use case.

I run a pinball museum. A volunteer offered to build a maintenance tracking system. For maintenance logs, we need to upload photos and video. For the video, he wants to transcode it to manage size and end up with a format everybody can view. He says, "I thought I could share a Railway file volume to share video files across both the web service and the worker service that transcodes videos.  However, this evening I discovered Railway doesn't support sharing volumes across services.  So now I'm having a re-think."

So as neat as Railway seems, this looks like a deal-killer for us. I want a hosting service where we can add on a variety of collaborating apps over time. If there's some short-term workaround, I'd go with it. But as many people have mentioned, this is a common docker-compose use case. I have to think we'll hit it again.

As an aside, I also find the minimal company response concerning. At the least I'd expect a pointer to what Railway expects developers to do instead. And given that the one employee comment sets a threshold that was met long ago, it makes me concerned that support is haphazard.