Ambient CI is the CI engine I’m building for myself, and tentatively for Radicle CI. I last blogged about it as a project over a year ago. Since then, the focus and goal of the project has crystallized in my head as:

• You should be able to run CI for other people safely and securely, without much effort.
• We as software developers should be able to share our computing resources with each other to run CI for each other. This should be safe and secure for us to do.
• We should be able to run CI locally and get the same exact results as when a server does it.

In other words, safe and securet distributed and local CI for everyone.

The approach I’ve taken is that any code from the software under test, or any of its dependencies, none of which can inherently be trusted, is only ever run in an isolated, network-less virtual machine. I’ve proven to myself that this works well enough. It will not, of course, work for any software project that inherently requires network access to build or test, but those are rare excecptions.

For now, I mostly care about automatically building software, and running its automated tests. Ambient can publish build artifacts with rsync and deb packages with dput; other delivery methods are easy to add, too. I have not worried about deployment, yet. Deployment seems a tricky problem in a distributed system, but I’ll worry about it when the integration parts work well.

Ambient is not there yet. It will take a lot more work, but there’s been some progress.

• Most importantly for me, I’ve integrated the Ambient engine with the Radicle CI subsystem. This is important to me because Radicle, the distributed Git forge, handles all the boring server parts and I don’t need to implement them. I get paid to work on Radicle CI and we’re experimenting with using Ambient as the default CI engine.
• I’ve used Ambient, with Radicle, as my primary CI system for this year. The combination has worked well. I also use GitLab CI on gitlab.com for one or two projects where I collaborate with people who don’t want to use Radicle.
• I’ve set up https://callisto.liw.fi/, a host that runs CI with Ambient+Radicle for open source Rust projects. See https://callisto.liw.fi/callisto/ for instructions, and https://blog.liw.fi/posts/2025/callisto/ for the announcement. I do this to get more experience with running CI for other people.

There are, of course, problems (see open issues). Apart from the recorded issues, I worry about what I don’t know about. Please educate me.

Two of the big problems I know about are:

• Before the actual build happens, in a network-less virtual machine, build dependencies need to be downloaded. I’ve only implmented this for Rust crates, and even that needs improvement. Other languages and other build dependencies need to supported too. This is an area where I will certainly need help, as I don’t know most language ecosystems.
• The dependency downloading and the delivery actions are run on the host system. Ambient needs to isolate them, too, into being run in a virtual machine. If nothing else, this relieves the host system from having go have language tool chains installed.
• So far I’m using a custom build Debian image for the virtual machine. I write my own VM image building software, so this is no big deal for me. However, Ambient really should be able to use published “cloud images” for any operating system, as a base image. I only deal with Debian, really, so I’ll need help with this, even for other Linux distributions. From a software architecture point of view, Ambient requires fairly little from the VM image. Maybe some day someone will add support for Windows and macOS, too.
• Ambient runs the VM using QEMU, and needs to unlock architecture support by not assuming VM image is in the host architecture. Emulating a foreign architecture is not very fast, but slow is better than impossible. Imagine being able to produce binaries for x86_64, aarch64, riscv64, and any of the other architecture QEMU supports.
• Ambient currently only supports a very straightforward CI run plan, with a linear sequence of actions to execute. Ambient needs to support matrix builds, and more generally build graphs. By build graphs I mean things like generating some artifacts once, then using those on a list of architectures to produce more, then process those artifacts once, and finally deliver some or all of the artifact to various places. In a distributed manner, of course.
• I need to learn how to count. I also need to learn to resist the temptation to make a tired joke about hard problems in computer science, but that keeps dropping out of my short term memory.

That’s where Ambient stands currently. It works, at least in my simple use, and it’s distributed.

If CI systems interest you, give Ambient a look. Let me know what you think, by email or on the fediverse.