Open-source Namespace alternatives

Earthly is a build framework with a syntax that resembles a mix of Dockerfile and Makefile. It describes itself as Docker for builds: you write a build once and run it on a laptop, on a remote machine, or in any CI system with the same result. It is written in Go and released under the MPL-2.0 license.

Its promises are repeatable builds, simple syntax, compatibility with any language or build tool that runs on Linux, suitability for monorepos and polyrepos, fast builds through caching and parallel execution, and reuse of build logic across projects. Containers underpin the isolation.

The README notes prominently that Earthly is no longer actively maintained, so teams considering it should weigh that against alternatives and consider community forks. It remains relevant for existing users and for those who want to study a container-based build system.

NativeLink is a high-performance build cache and remote execution server written in Rust. It speeds up compilation and testing by storing build artifacts so unchanged targets are not rebuilt, and by distributing build and test actions across multiple machines, which also helps reduce infrastructure costs for large projects.

It is compatible with Bazel, Soong, Pants, Buck2, Reclient and other build systems that support the remote execution API, and it supports specialized hardware for workloads such as GPU builds and simulation. The project highlights use cases including very large monorepos, robotics and autonomous vehicle stacks, semiconductor design flows and bioinformatics pipelines. It is powered by Nix, and the repository includes files for AI agents.

NativeLink is self-hosted infrastructure that teams deploy for their CI systems and developer laptops, and the README says it is used in production by the company behind it. The repository lists its licence as other, so check the project's terms before adopting it. It suits build and developer-productivity engineers who run large Bazel or Buck2 codebases.

RunsOn is a control plane for self-hosted GitHub Actions runners on AWS. For every workflow job it launches an isolated EC2 instance with a runner image compatible with GitHub's own Linux images, so existing actions and toolchains keep working while the compute runs in your own AWS account.

You keep control of IAM, networking, images, caches and the AWS bill, and the project says there is no per-minute markup, only spot or on-demand EC2 rates. Setup is done with a CloudFormation stack or Terraform module, runners scale back to zero when idle, and you can pick high-frequency instance families or GPU types. It is presented as an alternative to Actions Runner Controller without needing a Kubernetes cluster.

The repository is licensed under MIT and is meant to run inside your AWS account, with documentation and a cost calculator on the project website. Its topics mention on-premise and self-hosted runners as well. It suits engineering teams with heavy GitHub Actions usage who want to cut CI spend and gain more control over runner hardware.