Is there a reason why volumes are not attached during release_command
Short answer: yes.
Longer answer: a release_command creates a new machine, and
A Machine can only mount one volume at a time and a volume can be attached to only one Machine.
– Fly Volumes overview · Fly Docs
But a more helpful answer would be to find out what you are trying to do, and suggest alternatives. For example, if you are doing a migration with sqlite3, typically that involves creating a small script that does a migration and then runs the start command, and finally listing that script as the ENTRYPOINT.
If you can describe what you are trying to do, we can talk you through it.
I was hoping for something like init-containers from k8s.
Basically what I was after is a “run at deployment” script.
The goal is to build a python virtual environment and any other init setup to the volume once, and only at any given deployment. I know I can kinda fake this via a more complex entrypoint script, but that means the complexity and logic runs every startup, and that costs boot time.
Possibly dumb idea?
Build the python virtual environment at build time. Run the equivalent of cp -r (or shutil.copytree if you prefer) of the directory to another place. At startup, copy the directory to the volume.
I do something similar with my app: I build a demo (including running migrations against an sqlite3 database) during build time, and at deploy copy the resulting database to the right place.
Or, you can always try Introducing Fly Kubernetes · The Fly Blog
Unfortunatly that breaks virtual environments, they don’t like being moved.
Most of this problem comes from python being just a pain in the ass to deploy reliably 
The other question I had is, I wonder would it be possible to push an init style container to the registry and then boot a machine to run that container as a 1shot with the volume attached then destroy that machine detach the volume and fire up the actual app.
It means I deploy myapp-init which is the container that does the setup and then myapp after that fact.
I wonder.
I may have said it poorly, but I ask you: if I move the files and then move them back to what appears to be the same location, who would be the wiser?
In the build step, 'mkdir` the destination which would be the eventual mount point, build the virtual environment there, and then copy the result to a safe location.
In the deploy step, mount the volume, and copy the virtual environment back.
While that is possible (but would need to be scripted), it would involve taking down the running machine in order to release the volume, then starting a machine with a different image, writing to the volume, and then starting the image you ultimately want. That would take longer than running the script on the deployment machine in the first place.
The up, build, detach and down is a release step anyway, its fine to be slow.
Release slow boot fast 
As for your other point you make an interesting point, I shall give it a play tomorrow
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.