The idea is to ship a bash script that runs docker-compose under the hood and is doing the install/upgrade/whatnot.
That’s simply not true. You can share volumes just fine.
Because you live and breathe the code you wrote there.
Let’s put this in another perspective: Say I’ve just found out about ruby and want to write my own website. Instead of using RoR I’m writing my own thing that implements a WSGI subset and speaks directly to nginx. It works perfect, is extremely performant and easy to use for end users, but nobody ever understands what I wrote there.
It’s the same thing here. Instead of using something like docker-compose you wrote your own thing. That’s totally fine and was probably the right thing to do at this time. But really, only the team actively working on it understands what’s going on.
It basically comes down to: Do you want to take the longer road that people understand by using established tools, or do you prefer to use well working shortcuts nobody is able to follow (except the team) by writing your own thing?
Again, I totally understand why you did it this way. If you ever prefer to go down the docker-compose route, @ping me at GitHub and I’ll make sure to help you out with all roadblocks you might encounter.