Releases and nix (the package manager)

I do not think you could just blindly do this. The two things that come to mind are

1. Make sure you are not building on linux and deploying on mac (or vice versa)
2. I think CPU architecture plays a roll in this? So do not build on x86_64 and deploy to ARM. (But maybe if you don’t include ERTS, it isn’t a problem? I’m really not sure.)

I have also heard that you will want to use the same OS down to the patch level for building and running. Though, I am not really sure how much that is actually required.

I would truly love to hear from people that have actual knowledge in releases to be able to break down when and why the suggestions are so strong to run on exact same versions of things.

In this setup I can guarantuee, its always some linux flavor, never macOS. Also Processor architecture will always be the same.

So in other words, I have to test it on my own? I hope I can spare some time for that during the month…

I haven’t thought of using nix-copy-closure - good idea.

But I’m already building my releases with Nix and deploy the result via rsync to my Alpine Linux (musl) server.
Currently I’m only successful as long as I build the release without ERTS and make sure Erlang (same version as for building) is installed on the target server (nix-env -iA nixpkgs.erlangR22).
Overwise the release doesn’t find the native libraries (NIFs).

As nix-copy-closure will possibly copy the Erlang dependency anyway to the server it might work immediately - but I’m not sure about that.

For the future I hope I can build my release with a cross compiled Erlang within Nix, so even a build with ERTS included for a different target (musl, ARM, …) is doable very easy…

Edit:
I’ve just updated my elixir_nix_seed Repo regarding the releases.

I quickly asked about a scenario like this on the Erlang slack last night. Here are a couple quotes.

this is true if you use at least one of:

• include ERTS into your release
• use NIFs or ports
  In other cases you do not need to build and run release on the same OS version

only if you include erts or crypto, which are both compiled for particular versions of dynamicly linked libraries that if they different on the host they can’t run

probably different versions of libc and OpenSSL

These quotes actually came from @hauleth and @tristan.

With that said, I think those kinds of things would come along with your package in your scenario.