How Zed gets fast Rust builds and secures its OSS project with Namespace
“The product is so good. Compared to any other provider I’ve used, it’s just been completely seamless.”
Conrad IrwinSoftware Engineer, ZedZed is a fast, collaborative editor built to make it easy to work with both AI and other people. The team believes great software is built by teams working as effectively as possible, and that even in an AI-assisted world, that basic need is not going away. Zed is OSS and independent, which has made it especially popular in the OSS community, and it is increasingly showing up inside small and large companies alike. They’re trusted by Anthropic, Vercel, Apple, AWS, Atlassian, and so many more.
Because Zed ships a native, high-performance editor written in Rust, its continuous integration is unusually demanding. Every pull request has to compile and test a large Rust codebase across macOS, Linux, and Windows, and it has to do so quickly enough that contributors are not left waiting. As an OSS project that accepts pull requests from its community of users, Zed also has to treat its CI as a security surface.
Problem: slow Rust builds and Mac runners with operational overhead
Like most teams, Zed started on GitHub Actions. For a Rust project of Zed’s size, that meant living with two chronic problems: slow builds and painful caching. A typical uncached build ran about 20 minutes, and a release build closer to 40.
“One of the downsides of Rust is compile times are horrific, caching is horrible, and it’s just slow and yucky.”
macOS was the sharpest pain. Fewer providers support Mac runners well, so Zed had been running its own instances on MacStadium, the most affordable cloud Mac option they could find. The trouble was that those machines were stateful, and pretty much every day someone had to go in and restart one because it was stuck in some weird state. The runners were faster than GitHub Actions, but they came with constant babysitting.
Stateful machines were also a security liability. Zed is OSS, so anyone can open a pull request, and a stateful runner opens the door to one job leaving something behind that a later job picks up. A polluted machine could hand bad state to the main release builds, the ones that hold all the credentials. Conrad’s security team had spent months trying to retire those persistent boxes, including a set of Windows machines in Germany that existed only to run CI.
Solution: Selecting Namespace over GitHub and MacStadium
Zed needed runners that were fast, supported macOS as a first-class target, cached Rust dependencies well, and did not require someone to log in and reboot them. Namespace matched on every count. Its stateless VMs meant the daily restarts simply stopped happening, and the observability made it easy to see CPU, RAM, and storage usage in real time so the team could size machines correctly and get the most out of each build.
Caching was the feature that stood out most, because for Rust it is everything. Conrad described the landscape as a three-way split. GitHub Actions has no persistent cache, so you upload and download hundreds of gigabytes over the internet on every run. MacStadium is effectively all cache because it is the same machine every time, but that is exactly what creates the state pollution and reboot problems.
“Namespace caching gives you the isolation and the cleanness of the GitHub cache, but the performance is more like persistent machines.”
For a codebase that needs hundreds of gigs of Rust cache, that meant significantly better performance.
Zed had looked hard at the alternatives before landing here. They had used Semaphore at a previous company but found its Mac support lacking. They tried BuildBuddy with Bazel, and it turned into too much extra configuration work. They evaluated Buildkite and found it poorly integrated. Namespace, by contrast, just plugged into their existing GitHub Actions as a drop-in replacement with no extra permission layer to manage. And because those runners are built on the Namespace platform, with macOS instances and a range of machine shapes across Linux, macOS, and Windows, Zed got the full build matrix it needed without standing up its own fleet.
Results: 3x faster queue times, cleaner builds, and a locked-down project
The elastic, stateless infrastructure paid off immediately. Queue times dropped from nearly 2 minutes to about 40 seconds, and with cache volumes in place, builds that once took around 20 minutes can now finish in as little as 2 to 3, a speedup other providers could not match because their caching was so much slower. Just as importantly, the reboot toil disappeared and the security posture improved: stateless VMs remove the risk of a malicious pull request polluting a machine that later runs trusted release jobs. With cache volumes now shipping for Windows, Zed is preparing to move fully onto Namespace and finally retire those German CI machines.
The day-to-day experience is what Conrad keeps coming back to. The dashboard is his favorite, and a close second is the Slack channel where our team replies within seconds.
“My favorite thing is that dashboard. It’s super clean, everything is in one place, and I can see everything I want to see.”
If you’re wrestling with slow Rust builds you can’t trust, let us help. We know a better way. Reach out to join our OSS sponsorship program.
