Yeah, I get that containers allow the use of shared resources on a single host. The problem is that the same pattern has been used (and nested) in many places where it makes no sense. The render problem is that they support deploying dockerfiles, but not configuring the command to run the container on the host, which means you can't map volumes. The workaround is also really weird: https://community.render.com/t/map-disk-to-docker/4707/5
Discussion
I just read their persistent disk docs. Yeah that's a limitation of render and their filesystem policy, you can't even share the filesystem points, which is a nicely working feature of containers obviously. I guess they intend users rely on other persistent data methods for more complex sharing, which is probable the enterprise use case. Use S3, or a database don't use the filesystem.
To be fair though there are other reasons they may limit this. Often VPS providers use ramfs to keep things snappy because most apps don't need much space, and if you need a DB or some other large storage system they offer they separately. So they may provision X GB of storage, but it's sitting on an array somewhere so they map some, or all storage to memory, so they don't want people actually using the storage they pay for because they can't make the same performance guarantees. That's speculation based on what i've seen for small VPS (like 25gb or less of persistent storage)
That makes a lot of sense, and yeah, a lot of this comes from me trying to deploy strfry/lmdb on a PaaS 😂
I come from a hardware first background so much of this cloud stuff is still new to me as well.
