Perhaps this could use docker volumes?

There should be way to use docker volumes, maybe using docker-compose settings and option set which folder should be used as volume in dashboard too.

Another use case for this would be to run apps that use SQLite as their database, maybe combined with https://litestream.io

I'm fine with object storage, but I am fairly sure somebody is going to come along and say they need (mountable) persistent file storage across a service. This I'm also totally okay with, since I can use either.
I think the mountable file storage is a bit more flexible in the long run, considering that people may have applications or circumstances which make using object storage not possible or infeasible, and file storage is the most "standard" or most "compatible" solution, which is easy and works well across a wide range of languages
In addition to this, the mountable file storage option also allows people to use their own database like sqlite more easily
I don't think there needs to be shared disk across services (only persistent storage per service). If somebody needs to share data across services, they can use the planned feature to do internal network communication between services, can't they?

I'm fine with object storage, but I am fairly sure somebody is going to come along and say they need (mountable) persistent file storage across a service. This I'm also totally okay with, since I can use either.
I think the mountable file storage is a bit more flexible in the long run, considering that people may have applications or circumstances which make using object storage not possible or infeasible, and file storage is the most "standard" or most "compatible" solution, which is easy and works well across a wide range of languages
In addition to this, the mountable file storage option also allows people to use their own database like sqlite more easily
I don't think there needs to be shared disk across services (only persistent storage per service). If somebody needs to share data across services, they can use the planned feature to do internal network communication between services, can't they?

indominablerexx: +1, totally agree on that approach

Moving to planned: however, we need your help. We want to know if you mean something like built in object storage (hard) or mountable storage (hard, fs aint easy) or shared disk across services (very hard).
Your comments here help us sus out what would be the best effort/result from this endeavor.

Angelo Saraceno: Mountable fs storage for config files, and data generated by an application which persists over different deployments of a service.
That's the single thing blocking me from moving to Railway 🤷‍♂️

I'm fine with object storage, but I am fairly sure somebody is going to come along and say they need (mountable) persistent file storage across a service. This I'm also totally okay with, since I can use either.
I think the mountable file storage is a bit more flexible in the long run, considering that people may have applications or circumstances which make using object storage not possible or infeasible, and file storage is the most "standard" or most "compatible" solution, which is easy and works well across a wide range of languages
In addition to this, the mountable file storage option also allows people to use their own database like sqlite more easily
I don't think there needs to be shared disk across services (only persistent storage per service). If somebody needs to share data across services, they can use the planned feature to do internal network communication between services, can't they?

indominablerexx: Totally agree 💯

Moving to planned: however, we need your help. We want to know if you mean something like built in object storage (hard) or mountable storage (hard, fs aint easy) or shared disk across services (very hard).
Your comments here help us sus out what would be the best effort/result from this endeavor.

Angelo Saraceno: Docker volumes could enable most of these, imo. Until you at some point in the future implement object storage, users could roll their own with Minio. Backup support would be huge, too.

Moving to planned: however, we need your help. We want to know if you mean something like built in object storage (hard) or mountable storage (hard, fs aint easy) or shared disk across services (very hard).
Your comments here help us sus out what would be the best effort/result from this endeavor.

Angelo Saraceno: Mountable persistent storage seems the most common / compatible / standard solution to use. And it's the one I could use the most.

Moving to planned: however, we need your help. We want to know if you mean something like built in object storage (hard) or mountable storage (hard, fs aint easy) or shared disk across services (very hard).
Your comments here help us sus out what would be the best effort/result from this endeavor.

Angelo Saraceno: Voting for mountable storage that will let us use fs. We don't need sharing across services atm. Object storage is already solved by enough entities that can be easily plugged into Railway.

Moving to planned: however, we need your help. We want to know if you mean something like built in object storage (hard) or mountable storage (hard, fs aint easy) or shared disk across services (very hard).
Your comments here help us sus out what would be the best effort/result from this endeavor.

Angelo Saraceno: like docker volumes, so mountable storage. If you are deploying a CMS, persistent storage is a must!

Moving to planned: however, we need your help. We want to know if you mean something like built in object storage (hard) or mountable storage (hard, fs aint easy) or shared disk across services (very hard).
Your comments here help us sus out what would be the best effort/result from this endeavor.

Vasanth Srivatsa: Gotcha, naive question, why wouldn't these configuration files be committed to a repo? Just wanna capture the specific use-case for the team here.

Moving to planned: however, we need your help. We want to know if you mean something like built in object storage (hard) or mountable storage (hard, fs aint easy) or shared disk across services (very hard).
Your comments here help us sus out what would be the best effort/result from this endeavor.

Angelo Saraceno: I can't say for him, but for my specific case, I have generated runtime information (call it a local file db if you will) that needs to persist. My local file db isn't big or worth enough resources to put it in a MySQL/Redis db, so it's better over local.
This is especially useful for something like sqlite.
While object storage does work for this, it's generally easier to think about as a filesystem. Plus, I am certain there are tools out there that use the filesystem for this kind of stuff (maybe logs?), and aren't configured to use object storage.
(Don't get me wrong though, I think object storage is a very useful feature; but I think file system storage is more "standard" right now)

I'm fine with object storage, but I am fairly sure somebody is going to come along and say they need (mountable) persistent file storage across a service. This I'm also totally okay with, since I can use either.
I think the mountable file storage is a bit more flexible in the long run, considering that people may have applications or circumstances which make using object storage not possible or infeasible, and file storage is the most "standard" or most "compatible" solution, which is easy and works well across a wide range of languages
In addition to this, the mountable file storage option also allows people to use their own database like sqlite more easily
I don't think there needs to be shared disk across services (only persistent storage per service). If somebody needs to share data across services, they can use the planned feature to do internal network communication between services, can't they?

indominablerexx: +1

Moving to planned: however, we need your help. We want to know if you mean something like built in object storage (hard) or mountable storage (hard, fs aint easy) or shared disk across services (very hard).
Your comments here help us sus out what would be the best effort/result from this endeavor.

Angelo Saraceno: Besides the mountable storage it would be great if you can select a directory (e.g.: Uploads) which is not deleted after a new deploy. This would allow to use many systems, such as Strapi, Directus, Wordpress. In subdirectories images or plugins are stored, which must not be deleted after a new deploy. Please have a look at Render.com - they have integrated such a solution.

Moving to planned: however, we need your help. We want to know if you mean something like built in object storage (hard) or mountable storage (hard, fs aint easy) or shared disk across services (very hard).
Your comments here help us sus out what would be the best effort/result from this endeavor.

Vasanth Srivatsa: "That's the single thing blocking me from moving to Railway 🤷‍♂️" - same situation as mine!

I think having mountable PERSISTENT volumes (do no need to be shared among services) is a big win. This would basically allow us to run anything from a S3-like service, to custom DB etc.

Another case is when you want to host a https://www.meilisearch.com/ server. The data has to be persisted. An object storage will not cut for this case.

IN PROGRESS ❤️❤️❤️❤️❤️❤️

IN PROGRESS YEAAAAAA

Finally in progress <3 Hopefully mountable storage

Looks like this has been done!

https://railway.app/changelog/2023-06-23-volumes-priority-boarding