thiagomajesk
Performance and security advantages of mix releases
Hello everyone!
I was discussing with a colleague at work today about the possible use cases that would require using a mix release and I would like to know if there are any gaps in my current understanding of when you should reach out to a release versus simply running the code with mix.
BTW, I already know we have an excellent topic in the official docs about releases here and many other topics in the forums as well, but I want to contextualize some things first so you can have a better understanding on why I’m asking about this now…
The way I’ve always seen it, the main advantage of releases has always been the fact that it’s self-contained. However, I don’t think I’ve seen many topics about other aspects, like configuration, performance, and security (just to name a few).
I’ve been coding in Elixir for quite some time now and for the times I used Phoenix in production I have always deployed it using releases (mostly for convenience), and I must say that I’ve never needed to tweak the VM configurations beyond the very basics. So in a way, I could say that I haven’t used release’s “full potential” yet (so to speak).
Performance-wise, my current understanding is that there are some out-of-the-box improvements because of code preloading and the custom flags that you can pass to the VM and that’s it.
I never managed to find the time to dive too deep into Elixir/Erlang internals, but I have the impression that sometimes people can be led to think (in a very strict way) of something like mix phx.server as “development mode only” and running it as a release as “production mode only” (mainly because mix is in fact, a development tool).
So, just to clarify: I’m asking because I want to be better equipped to answer this type of question in the future in a very objective way and I hope that the answers to this thread can shed some light on this particular portion of the subject - as we all know, developers can sometimes be very “dogmatic” about their ways so this would help destigmatize the subject a little bit. Cheers! 
Most Liked
benwilson512
Pretty sure this thread is still relevant Always use Releases
voltone
The EEF Security WG’s deployment hardening guidelines document has some things to say about the security benefits of releases.
LostKobrakai
In the end many things will be the same between using releases or not. There will always be the erlang VM (globally installed or in case of releases it also can be bundled), there will always be (a subset) of otp applications, there will always be the applications you depend on, there will always be your application(s). Unless you specifically work around that modules once compiles should result in the exact same bytecode being executed.
The parts where things differ are how things are started up / loaded, how many additional applications or pieces of code will run and potentially how local the parts needed to run are to themselfes on the filesystem.
Judging which option is ok or not depends on how much those differences are worth to people.
Most often I’d expect some (sub- or superset) of the following:
- Precompiling saves resources on the app server in favor of doing it on a build server
- Shipping only compiled data and no longer needing source files makes deployments faster
- Bundling everything (including erts/otp) makes a release less dependant on preexisting things on an app server
- Bundling just exactly everything lessens the overhead when running a release
- Precompiling enforces a differenciation between config being applied to compiled code or config being provided at runtime and not compiled into changes of code
- Start scripts show exactly in which order things are started up, which aids debugging
- Releases come with helpful script for remote access, rpc without the overhead of needing all of Mix to run a mix task
- While the prev. might be a downside this means there’s a clear differenciation what would be used on a production system vs on a development system
There are likely more. But I don’t think there’s any hard facts pushing this (way) beyond “conveniences”.
Popular in Discussions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Move fast and fix things! Error tracking with less noise for Elixir devs who love to ship. Start your free dev account.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"