# Hex, the package manager that ships as Mix tasks

> Hex is the package manager for the Erlang ecosystem, and the repository you are looking at is the client side of it, delivered as tasks that integrate with Mix, Elixir's build tool. Two details are worth knowing before you rely on it, the bundled root certificate list that has to be refreshed from Mozilla, and the integration test suite that expects a local hexpm server and a PostgreSQL instance.

**hexpm/hex** — Package manager for the Erlang ecosystem.

- Repository: https://github.com/hexpm/hex
- Website: https://hex.pm
- Stars: 1,088 · Forks: 215
- Language: Elixir
- License: not declared
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/hexpm-hex

## The client half of a package registry

Hex is a package manager for the Erlang ecosystem, and the repository holds the part of it that a developer installs. The README is precise about that boundary, saying the project currently provides tasks that integrate with Mix, the build tool of Elixir. So the thing in this repository is not the registry, it is the set of tasks a developer runs to add a dependency, to publish a package, and to talk to the registry over the network. The registry and the public package site live elsewhere, at hex.pm, which is also where the installation instructions and the rest of the documentation are, and the README sends you there rather than duplicating it. The audience is therefore two groups, an Elixir or Erlang developer using the package workflow day to day, and a contributor who wants to work on the client, the tests or the build. Understanding that split early saves a lot of confusion, because a question about publishing policy or about what a package page looks like is answered on hex.pm, not here.

## Root certificates are compiled into the artefact

The most interesting mechanism in the repository is the certificate bundle, and it is unusual enough to be worth reading twice. Hex performs HTTPS certificate validation, and instead of trusting the operating system store it bundles its own list of root CA certificates. The list is fetched from Mozilla's source tree using curl's mk-ca-bundle.pl script, the resulting bundle is stored as lib/hex/http/ca-bundle.crt, and that file is committed to source control rather than downloaded at install time. When Hex is compiled, the certificates are parsed and included with the compiled artefacts, so the trust anchors travel inside the binary. The README also says the file should be updated when new releases are made by Mozilla, and that a task called mix certdata automates that process. The design has clear virtues for a package manager, since a client that carries its own anchors does not depend on the host's certificate store, and the cost is a recurring maintenance chore that belongs to the maintainers rather than to you, with a stale list showing up as an HTTPS validation failure that looks nothing like a package problem.

## Integration tests need a hexpm and a database

The test suite is split, and the integration part expects infrastructure that a contributor has to provide. The integration tests run against the API server, which is the separate hexpm project, and the README explains the two ways to make it available. Either the hexpm repository is cloned into../hexpm next to this one, or the HEXPM_PATH environment variable is set to point at its location. The server in turn requires PostgreSQL, with the username postgres and the password postgres, which is a local development convention rather than a production one. When that infrastructure is not available, the documented way to skip those tests is to exclude them by tag.

```bash
mix test --exclude integration
```

That exclusion keeps a local test run from failing on a missing database. The password in the README being postgres is also the clearest signal about the intended scope, this is a development setup talking to a local database on a developer machine, not a configuration anyone should copy into a shared environment.

## A small repository with a conventional layout

The top level listing is short and follows the usual Elixir project conventions. lib/ holds the Elixir code, and the presence of lib/hex/http/ca-bundle.crt tells you where the certificate bundle lives inside it. There is a src/ directory and a scripts/ directory for helper scripts, plus config/ for the application configuration and test/ for the test suite. The build description is mix.exs with a mix.lock for the dependency versions, which is the standard Elixir pair. The tooling configuration is equally conventional..formatter.exs configures the code formatter, which is what keeps mix format from producing diffs in a pull request, and.credo.exs configures Credo, the static analysis tool that Elixir projects use for the checks a compiler will not do. On the process side, the tree carries CHANGELOG.md, RELEASE.md for the release procedure, and a.github/ directory with the workflows. There is a.gitignore and a.formatter.exs at the root, and the repository is otherwise unremarkable, which is a compliment for a package manager client.

## Patch releases and a steady branch

The release history shows a project in maintenance mode rather than in upheaval. The recent tags are v2.5.1 on 2026-07-09, v2.5.2 on 2026-10-12 and v2.5.3 on 2026-10-14, so the version has moved through the 2.5 line with patch releases and no major bump in sight. The last push was on 2026-10-15, the day after the newest tag, so the branch moves quickly after a release. For a consumer this is a good pattern, since a package manager that changes its behaviour between minor versions would be a nuisance, and a patch level bump rarely changes anything a user has to think about. The one caveat is the same one that applies to any client with a bundled trust store, the interesting changes in a patch release are often the certificate refresh, because that is the file the maintainers regenerate whenever Mozilla publishes, and a diff that looks like a wall of base64 is a maintenance task rather than a code review.

## Licence terms and the certificate question

The README carries the Apache License, Version 2.0, with the copyright attributed to Six Colors AB and dated 2015. The project licence field on the hosting side is recorded as unknown, which is a metadata gap rather than a contradiction, since the file in the tree is the authoritative statement and the README reproduces it in full. For a company shipping a build that includes Hex, the Apache 2.0 terms are the ones to plan around. The question that the README does not answer is the one about the bundled certificate list. The certdata file is derived from Mozilla's published certificate source, so an organisation that vendors the compiled artefact is vendoring that derived file as well, and whether that carries separate obligations is a question for whoever handles licensing rather than for this document. Nothing here is legal advice, and the practical advice is only that the file is committed to the repository, so it is visible in the diff, which makes the review straightforward once someone has looked at it.

## Conclusion

Hex fits an Elixir or Erlang project that pulls dependencies from hex.pm and wants that workflow to keep working over HTTPS, and it fits a contributor who wants to work on the client itself, since the build and the test setup are documented in the README. It does not fit a team that wants the package registry itself, because the server side lives in the separate hexpm project, and it does not fit a project that must control its own trust anchors, since the certificate list is bundled into the compiled artefact. Verify three things first: that the bundled certificate list is current for your environment, since it is refreshed only when Mozilla makes a release and a stale list shows up as an HTTPS failure rather than as a package error, that a hexpm checkout and a PostgreSQL instance are available if you intend to run the integration tests, and which licence terms apply, since the README states Apache 2.0 while the project licence field is recorded as unknown.

## FAQ

### What is Hex?

Hex is a package manager for the Erlang ecosystem. The repository holds the client side, which provides tasks that integrate with Mix, the build tool of Elixir, while the public package site and installation instructions live at hex.pm.

### How does Hex validate HTTPS certificates?

Hex bundles its own list of root CA certificates, fetched from Mozilla's source tree with curl's mk-ca-bundle.pl script and stored as lib/hex/http/ca-bundle.crt in source control. The certificates are parsed when Hex is compiled and included with the compiled artefacts, and the mix certdata task automates refreshing the list.

### What do I need to run the Hex integration tests?

A checkout of the hexpm API server, either cloned into ../hexpm or pointed at by the HEXPM_PATH environment variable, and a PostgreSQL instance with the username postgres and the password postgres. Without that infrastructure, run the suite with mix test --exclude integration.

### How do I install Hex locally for development?

The README says to install Hex locally for development with mix install. For using Hex itself, the installation instructions and other documentation are on hex.pm.

## Sources

- [hexpm/hex on GitHub](https://github.com/hexpm/hex)
- [Issues](https://github.com/hexpm/hex/issues)
- [Project website](https://hex.pm)
- [README](https://github.com/hexpm/hex/blob/main/README.md)
- [Releases](https://github.com/hexpm/hex/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hexpm-hex