I have been working on a rebar3 plugin/library for the last few days that allows you to build OCI compliant container images from Erlang and Elixir releases. At my company we’re using quite a few different languages, and some of them (C# and Golang are quite popular) have the ability to build container images directly without having to go through Docker. This results in incredibly fast build times on CI/CD pipelines.
I was a bit jealous of this for my Elixir projects, so I looked into if it was possible to do so for BEAM languages. With a lot of help from my good friend Claude we made fast progress, and tonight I released the first v0.1.0 release to Hex.pm.
Disclaimer: I’ve not written much Erlang before, but I decided to write this in Erlang instead of Elixir in order to make it easier for all BEAM languages to take advantage of this.
During the last few days I’ve implemented quite a few new features from my roadmap for
this library. I just released v0.5.0 which includes the following new features.
Multi-Platform Images
We can now build images for multiple platforms using a single command.
All downloading and uploading of layers now runs in parallel.
Multi-arch manifest follows the standard OCI format.
Non-Root containers by default
Runs as UID 65534 (nobody) by default, can be overridden using the --uid flag.
Automatic OCI Annotations
Generate OCI labels/annotations automatically from release version and VCS (only tested with Git for now).
Reproducable Builds
Respects the SOURCE_DATE_EPOCH env variable to override container file timestamps. This allows us to create reproducable builds given the same input.
Automatic Software Bill of Materials (SBOM) support
SPDX 2.2 SBOM are included in every image.
Can also be written to file using the --sbom flag.
Smart Dependency Layering
ERTS, dependencies, application code and SBOM are written as separate layers, meaning that only changes are pushed to registry. This results in typically 80-90% smaller uploads.
There’s probably still a few rough edges and the code-base needs a bit refactoring in certain places, but I have implemented most of my planned features and would be very happy for feedback (both positive and negative)!
As stated earlier, I’m, quite fresh in Erlang (even though I have been coding Elixir for quite some time), so there might be conventions and other things that could use some polish.
Just a small update on the latest work on this library. I’ve now implemented all planned features and made significant improvements on the code base, both in terms of code organization, test coverage and security measures.
The library now has the following feature table.
Feature
Status
Description
No Docker required
Builds images directly without container runtime.
OCI compliant
Produces standard OCI image layouts.
OCI annotations
Add custom annotations to image manifests. Automatically populate source URL, revision, version from VCS.
Push to any registry
Docker Hub, GHCR, ECR, GCR, and any OCI-compliant registry.
Build system integration
Native rebar3 and Mix task support.
Non-root by default
Run as non-root (UID 65534) by default; override with --uid.
Layer caching
Base image layers cached locally for faster rebuilds.
Tarball export
Export images for podman, skopeo, crane, buildah, etc.
Multi-platform images
Build for multiple architectures (amd64, arm64) from a single command.
Reproducible builds
Identical images from identical inputs using SOURCE_DATE_EPOCH.
Smart dependency layering
Separate layers for ERTS, dependencies, and application code.
SBOM generation
SPDX 2.2 SBOM embedded at /sbom.spdx.json and attached via referrers.
Image signing
Sign images with ECDSA keys (cosign-compatible format).
Zstd compression
Automatic zstd on OTP 28+ (20-50% smaller, faster). Falls back to gzip on OTP 27.
*Disclaimer: The claim about pushing to “any” registry is theoretical. I’ve actually only tested it with ghcr.io.
The library should be on par (or better) feature-wise with comparable libraries from other eco-systems (ko for Golang, Microsoft.NET.Build.Containers for .NET and jib for Java). It will remain in v0.x.x for a while to gather real-world experience and fixing bugs that certainly will pop up, but it should be in a pretty good shape.
This looks interesting. Given you‘re not running any container this won’t help with compiling NIFs for the target architecture though I guess. So just like ERTS they would need to be handled out of band. This still looks like a great option for where that‘s not needed.
That’s correct. If you’re building images for another platform you’ll need to either have to cross-compile your NIFs with a toolchain for that platform, or use a custom base image which contains ERTS and your NIFs already in place. The upside is that you’ll only have to build this base image once instead of on every build.
