Thanks for the comment! I actually looked into both of those things and I’ll try to address both of them.
-
Multi stage builds are great when you need to run two different containers like what is being shown in this guide (the first having Elixir and all of those goodies installed for building the release and the second just having Erlang installed). However, a major goal of this deployment strategy was to be able to compile releases on any machine, whether it is your development machine, a staging machine, or any other machine. This way, you can compile the release in the first stage, and the copy it to your deployment machine to actually run the release. This is intentional as I have a lot of low cost servers which can’t handle the actual compilation of the release, so I must do that first stage elsewhere. If you are sure that you wanted to do both steps on your deploy machine, then multi-stage builds would be perfect for this! This just isn’t a goal of my strategy.
-
Yes. The only reason that I didn’t include this in my guide is that most of my apps are seeded with data at startup, so they don’t “lose” any data if the database goes down. Therefore, I don’t really have much data to be lost so I didn’t consider it a part of my strategy. However, I’ve been thinking about this and in order for this strategy to be applicable to more kinds of apps I definitely need to explain how to do this. For that reason, I totally agree with you and I plan on updating the guide soon with another section on how to do that!
Awesome suggestions 
