This is non-exhaustive, and some of my concerns are more subjective than others due to my surrounding technology preferences, like my affinity for Docker/Kubernetes. Anyway, here goes:

• To my knowledge, ASDF and its plugins have never gone through any kind of security audit. If you don’t also own the infrastructure implementation, good luck convincing a disciplined infra/ops team that this is the way to go.
• While not nearly as insidious as similar tools like rvm, which makes extensive alterations to the shell’s core behavior, ASDF still entails prepending to your PATH and transparently overriding any conflicting binaries that might exist in the system-level PATH. In a server context, that’s a bug, not a feature.
• Simply activating ASDF’s core behavior requires sourcing shell scripts that you must implicitly trust to not introduce security flaws or behavioral problems. Right now all they do is set PATH and shell completions.
• With ASDF comes a reduction or absence of ownership of your foundational supply chain - you are (perhaps blindly, unless you go RTFS) trusting that ASDF is installing a secure, accurate, and unmodified instance of the language runtime, and that it will always continue to do so. Review of the installation methods is a community effort with no official involvement or oversight by OS/distribution maintainers or language authors.
• ASDF makes no assertions about the reproducibility of the language installs it provides, and asdf-erlang by way of kerl defaults to building OTP from source while linking system-level libraries. Different hosts will produce subtly different versions of Erlang over time, albeit in ways that rarely bite us in practice. This can be mitigated by:
  • Preferring pre-built OS packages (even if you start to maintain your own with something like fpm)
  • Adopting something like Nix/Guix that has stricter guarantees about provenance, checksums, etc.
  • Replacing shared-host-level runtime environments with immutable/reproducible artifacts, such as Docker containers
• If the use of ASDF on the servers extends to a fleet of actual application servers, you’re repeating all of that build-OTP-from-source work for each host, when a build-once approach is preferable. (Folks who come from a Ruby background remember the pain of Nokogiri compilation needing to happen on each runtime host.)
• The desire for server-side ASDF implies a couple possible practices are in place within your organization, one of which I find especially troubling. I strongly disagree with multi-tenancy of applications using disparate versions of the BEAM runtime on the same host, without using ERTS-included releases, and/or without applying an isolation technique like LXC/Docker/BSD jails/Solaris zones.

The tiny pragmatist inside me will acknowledge that most of these aren’t really pertinent if you’re only installing ASDF in a CI environment or a build host in an edeliver-ish stack. Since those aren’t using ASDF on a production server, I still don’t recommend it but I have far fewer objective qualms with it.

I would maintain that there are significantly better approaches to achieve the same goals, once people are able to separate the specific goal from the existing, known, sub-optimal tools to get there. I’ve mentioned a couple throughout the post.

ASDF should be viewed as a development tool, not a service dependency IMO. Our approach is to have ASDF installed on development and build hosts and using that to build a deployable artifact (RPM, tar, container, etc) which includes the Erlang runtime. The artifact is then installed on the target host and configured appropriately based on the deployment environment.

Edit: Another advantage is that the deployable services are now language agnostic - a big plus if you work in a polyglot environment.

I agree with this so also want to know @shanesveller reasons not to use asdf in production. Using it has allowed me automate release builds of multiple elixir projects (with different erlang/elixir versions) on my build server which emits releases. If my .tool-versions file references an erlang/elixir version that does not yet exist on the build server then it automatically downloads and builds the proper versions from source achieving dev/prod parity.

I agree it’s not necessary to install asdf on the actual production servers running the built releases as they are fully self-contained… hoping that is what he meant.