Persistent Storage
complete
J
Jake Runzer
complete
https://docs.railway.app/reference/volumes
Boring Dragon
Looks like this has been done!
L
Lucas
Finally in progress <3 Hopefully mountable storage
hmmhmmhm
IN PROGRESS YEAAAAAA
J
Jonathan Schneider
IN PROGRESS ❤️❤️❤️❤️❤️❤️
Angelo Saraceno
in progress
Njogu Amos
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.
Honza Sterba
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.
indominablerexx
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?
JuanM04
indominablerexx: +1, totally agree on that approach
Vasanth Srivatsa
indominablerexx: Totally agree 💯
Juan David Campiño
indominablerexx: +1
Angelo Saraceno
planned
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
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 🤷♂️
therecluse26
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.
indominablerexx
Angelo Saraceno: Mountable persistent storage seems the most common / compatible / standard solution to use. And it's the one I could use the most.
K
Kishan Bagaria
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.
Piccolo olocciP
Angelo Saraceno: like docker volumes, so mountable storage. If you are deploying a CMS, persistent storage is a must!
Angelo Saraceno
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.
indominablerexx
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)
J
Jonathan Schneider
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.
J
Jonathan Schneider
Vasanth Srivatsa: "That's the single thing blocking me from moving to Railway 🤷♂️" - same situation as mine!
Load More
→