• Developer
  • Erlang

Erlang projects keep a _build folder each, and rebar3 keeps a shared cache on top

rebar3 stores Hex packages in ~/.cache/rebar3 and compiles every project into its own _build folder. How to measure both on a Mac and what is safe to delete.

3 min read

Erlang space hides in three places: the shared rebar3 cache, a _build folder inside every project, and any Erlang versions you compiled with kerl or asdf. The last one is usually the largest.

du -sh ~/.cache/rebar3 2>/dev/null
du -sh ~/.kerl/builds ~/.kerl/archives 2>/dev/null
find ~ -maxdepth 5 -type d -name _build -prune -exec du -sh {} + 2>/dev/null | sort -h

That last command also finds Elixir projects, which use the same _build name. Both are safe to delete in projects you are not working on.

What to delete

  • ~/.cache/rebar3: downloaded Hex packages and registry data. Safe to delete; rebar3 fetches what it needs on the next build.
  • _build in a project: compiled output and fetched dependencies. Deleting the folder is the complete version of rebar3 clean -a.
  • ~/.kerl/builds: source trees left over from compiling Erlang. kerl cleanup all removes them and keeps your installed versions.
kerl cleanup all
rm -rf ~/.cache/rebar3
# In an old project:
rm -rf _build

Elixir's own caches are in Elixir Hex and Mix caches, and runtime versions from asdf or mise are in version managers taking up space.

Common questions

Where does rebar3 cache packages on a Mac?

In ~/.cache/rebar3, which holds downloaded Hex packages and registry data. It is safe to delete, and rebar3 downloads what a project needs on the next build.

Is it safe to delete the _build folder in an Erlang project?

Yes. It holds compiled output and fetched dependencies, and rebar3 recreates it on the next compile. Your source code and rebar.config are not inside it.

Why is ~/.kerl so large?

kerl keeps the source tree of every Erlang version it compiled. Running kerl cleanup all removes those build trees without uninstalling the versions you use.

Read next