Hex and Mix: Package Management as Part of the Elixir Developer Experience
Hex and Mix made dependency management feel native to Elixir: projects declare packages in mix.exs, resolve through Hex, lock exact versions, and publish with the same build tool.
Elixir treated build tooling and package management as part of the language experience
Elixir shipped with Mix, a build tool that creates projects, compiles code, runs tests and manages dependencies. That integration meant dependency management did not have to emerge as a separate third-party convention after the language matured. When Elixir 1.0 arrived in 2014, the official announcement already described Mix as the build tool responsible for project generation, compilation, testing and dependencies.[1] The package workflow could therefore grow inside the same command environment developers used for the rest of the project lifecycle.
One tool connected package operations to ordinary development tasks
Compiling, testing and fetching dependencies became related Mix tasks rather than separate administrative systems with different configuration models.
Hex was announced in 2014 as a package manager for the Erlang virtual machine ecosystem
José Valim announced hex.pm alongside Elixir 0.13 in April 2014, describing Hex as a package manager for the Erlang VM that could publish projects, fetch packages and perform dependency resolution.[1] Although the first integration focused on Mix, the ambition extended beyond Elixir to other languages and build tools on the BEAM. The modern Hex service describes itself as infrastructure for the broader BEAM ecosystem, including an HTTP API, repository, indexes, documentation hosting and integrations with Mix and Rebar.[2]
mix.exs made dependencies ordinary project configuration
Elixir projects declare dependencies in mix.exs alongside other project metadata. Dependencies without an explicit Git or path source are handled by Hex, so a declaration such as a package name plus version requirement is enough to enter the registry workflow.[3] This makes third-party libraries feel like a language-native concept. The build tool knows how to resolve, fetch, compile and place them in the project’s dependency graph.
The registry is the default rather than a special source
Git dependencies remain possible, but the normal path encourages published, versioned packages with registry metadata and a stable package identity.
mix.lock separated flexible version requirements from reproducible resolutions
Hex integrates with Mix dependency resolution and records selected versions in the project’s lockfile.[3] Developers can express a compatible range while committing the exact resolved graph so teammates and CI use the same releases. Updates are explicit operations that unlock and resolve dependencies again. This balances ecosystem evolution with reproducibility: package authors can publish new compatible versions without silently changing every existing build immediately.
Publishing used the same Mix interface as consuming packages
Hex’s publishing workflow asks authors to add package metadata to mix.exs and then run mix hex.publish.[4] The service packages the selected files, uploads the release and makes it available through the registry and CDN. Documentation can be published alongside the package to HexDocs. This tight feedback loop lowers the barrier between using libraries and contributing them: the same project description that builds an application also contains much of what is needed to release a library.
Documentation became part of package distribution
A package registry is more useful when users can move from a dependency declaration to generated API documentation without discovering a separate hosting convention.
Hex broadened beyond public packages into organizations and multiple build tools
The modern Hex service supports private organizational repositories and clients beyond Mix, reflecting its BEAM-wide scope.[2] Erlang projects can use Rebar integrations while Elixir retains its native Mix workflow. This distinguishes Hex from a registry tied narrowly to one compiler front end. The repository is shared infrastructure for languages that converge on the Erlang virtual machine.
Supply-chain controls became part of the dependency resolver itself
By 2026 Hex documented dependency cooldowns and signed organizational policies that can exclude newly published, vulnerable or retired releases during resolution.[5] These features show how package managers have evolved beyond choosing versions. The resolver can now encode organizational risk policy, allowing teams to delay fresh releases or block candidates based on advisory information before those packages enter a build.
Dependency policy moved closer to dependency selection
Instead of relying only on external scanners after installation, the package manager can refuse certain candidates while constructing the graph.
Why Hex and Mix belong in package-management history
Hex and Mix belong in package-management history because they made package operations part of the normal Elixir development surface. Project metadata, dependency resolution, lockfiles, compilation, publishing and documentation are connected through tools developers already use.[1][3][4]
The ecosystem also shows the value of designing package management early in a language’s life. Elixir did not have to retrofit a dominant ad hoc convention years later. Hex could grow in parallel with the community while Mix supplied a stable integration point.
As the registry matured, it gained the same concerns seen in older ecosystems: private packages, security policy, CDN delivery and operational governance. The historical lesson is that language-native package management begins as developer convenience but eventually becomes critical infrastructure. Hex’s success made dependency management feel invisible precisely because it was woven so deeply into the Elixir workflow.
Works Cited
- 01Elixir — v0.13.0 Release and hex.pm Announcement elixir-lang.org
- 02
- 03
- 04
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead