Introduction

If you need a specific Erlang/OTP release, the most reliable approaches are usually a version manager such as asdf or kerl, or a source build from the exact OTP release tag. System package managers can work, but they are often less predictable because older versions may disappear from the repository or differ by operating system.

So the first practical decision is this: if you need repeatable developer installs or multiple OTP versions side by side, use a version manager. If you need full control over build flags, install from source.

Using asdf for Repeatable Version Management

asdf is a common choice when you want to switch OTP versions easily.

First add the Erlang plugin if it is not already installed:

asdf plugin add erlang

See available versions:

asdf list all erlang

Install a specific release:

asdf install erlang 27.3.4.1

Set it for the current project:

asdf local erlang 27.3.4.1

Or set it for your user account:

asdf global erlang 27.3.4.1

This approach is convenient because the version selection is explicit and easy to automate in development environments.

Using kerl for Erlang-Focused Management

kerl is another popular option, especially in Erlang-heavy environments.

Build a specific release:

kerl build 27.3.4.1 otp_27_3_4_1

Install that build into a chosen directory:

kerl install otp_27_3_4_1 "$HOME/erlang/27.3.4.1"

Activate it in the shell:

. "$HOME/erlang/27.3.4.1/activate"

kerl is attractive when you want several isolated Erlang builds with different configuration options.

Building from Source

If you want maximum control, install from the exact Erlang/OTP release source.

A typical source-based flow is:

1wget https://github.com/erlang/otp/releases/download/OTP-27.3.4.1/otp_src_27.3.4.1.tar.gz
2tar -xzf otp_src_27.3.4.1.tar.gz
3cd otp_src_27.3.4.1
4./configure
5make
6sudo make install

You can also build from a git checkout of the matching tag:

1git clone https://github.com/erlang/otp.git
2cd otp
3git checkout OTP-27.3.4.1
4./configure
5make
6sudo make install

Source installation is slower, but it gives you exact version control and build-time flexibility.

Verifying the Installed Version

After installation, confirm the runtime version directly:

erl -eval 'erlang:display(erlang:system_info(otp_release)), halt().' -noshell

Or from the Erlang shell:

erlang:system_info(otp_release).

That check matters because systems with multiple Erlang installations can easily pick up the wrong erl executable from PATH.

Package Managers Are Sometimes Fine, but Less Reliable

If your operating system package manager already offers the exact version you need, it can be the simplest route. The problem is long-term reproducibility. Specific OTP versions are not always retained forever in distro repositories, and the naming conventions differ across platforms.

That is why teams that care about exact version matching often prefer asdf, kerl, or source builds instead of relying solely on apt, yum, dnf, or brew pinning.

Dependencies and Build Environment

Erlang builds often need development dependencies for SSL, terminal support, and compilation tools. If a build fails, the problem is frequently not the OTP version itself but a missing system library or compiler dependency.

That is another reason version managers are convenient: they standardize the version selection, while your team can separately document the required system packages for each platform.

Common Pitfalls

The biggest pitfall is assuming the operating system repository will always keep the exact OTP version you need. That may work today and fail later when older packages are removed.

Another common issue is installing the correct version but leaving PATH pointed at a different Erlang executable. Always verify with erl after installation.

Developers also forget that build dependencies matter. If configure or make fails, the missing piece may be OpenSSL headers, compiler tools, or another native dependency rather than Erlang itself.

Finally, if a project depends on an exact OTP patch release, record that version in the repo and use a tool that can recreate it consistently instead of depending on memory.

Summary

• For exact Erlang/OTP versions, prefer asdf, kerl, or a source build.
• 'asdf is convenient for project-local or user-wide version selection.'
• 'kerl is strong when you want isolated Erlang builds and multiple side-by-side installs.'
• Source builds give maximum control when you need an exact release and custom configuration.
• Always verify the active runtime version after installation because PATH issues are common.