When we started kicking the tires with env zero, I put together a demo to show how MultiTool could run inside their Workflows. The goal was to mirror a realistic setup reflecting how a team might actually integrate MultiTool into their deployment pipeline.
While the demo worked end-to-end, it was very slow. It wasn’t coming from MultiTool itself, but from the fact that I had to build the MultiTool binary from source before I could execute it. In total, that added roughly 20 minutes to every run. For a demo, it was annoying. For a real workflow, it would be a constant drag on iteration speed. We didn’t have this problem on other CI/CD systems like GitHub Actions because we usually download our pre-built binaries. But our binaries couldn’t run on env zero containers.
Most Linux systems rely on glibc, the GNU C standard library, as their standard C implementation. It’s the de facto standard for Linux OSs. Most people use it without even knowing.
The images env zero uses to deploy their workflows, however, don’t include glibc. They’re intentionally built to be lightweight, which is a common and increasingly important optimization in modern cloud infrastructure. When you’re running ephemeral workflows, generating images on every commit, or managing large fleets of containers, image size starts to matter in very concrete ways. Cold start and network transfer times, disk usage, and long-term storage costs all add up.
This is why many platforms move away from heavier base images. The stock Ubuntu Jammy image clocks in around 4.7GB, while something like Alpine Linux is closer to 5MB (nearly three orders of magnitude smaller!). At scale, those differences translate directly into real infrastructure costs.
Alpine Linux uses MUSL instead of glibc. MUSL is a lightweight implementation of the C standard library that’s designed to be small, simple, and predictable. It’s well suited for environments that prioritize minimal images and fast startup times.
The downside is that binaries built against glibc won’t run on MUSL-based systems without recompilation. That’s exactly what we encountered when adding support for env zero Workflows: every run had to rebuild MultiTool from source to produce a compatible binary.
Once that was clear, the fix was less about optimizing the build and more about changing what we shipped.
We added support for building MultiTool against MUSL and now ship a pre-built binary that runs on MUSL-based systems like Alpine Linux. With that in place, env zero workflows can simply download and execute the binary directly, rather than compiling it during the run.
In practice, this removes the ~20 minute build step entirely. The workflow becomes faster and more predictable, and MultiTool fits more naturally into an environment that’s already optimized for lightweight execution.
This change wasn’t driven by a roadmap item or a feature checklist. It came from trying to run MultiTool in a real workflow and noticing where the friction showed up. env zero made deliberate choices to optimize their execution environment, and it made sense for MultiTool to meet them where they are rather than working against those constraints.
MUSL support isn’t the kind of feature that shows up prominently in a demo, but it has a direct impact on how usable the system feels day to day. Shaving 20 minutes off a workflow run is meaningful, especially when it happens every time you deploy.
