> Cirrus CI will shut down effective Monday, June 1, 2026.
And earlier in the article:
> Joining OpenAI allows us to extend the mission we started with Cirrus Labs: building new kinds of tooling and environments that make engineers more effective, for both human engineers and agentic engineers.
It isn't a product-led acquisition, but more a talent one.
> In the coming weeks, we will relicense all of our source-available tools, including Tart, Vetu and Orchard under a more permissive license. We have also stopped charging licensing fees for them.
Hopefully development on it continues, or a community maintained version keeps it going.
> In the coming weeks, we will relicense all of our source-available tools, including Tart, Vetu and Orchard under a more permissive license. We have also stopped charging licensing fees for them.
Looks like I’ll need to move the FreeBSD CI jobs for open source projects I maintain to another solution. Anyone have suggestions for alternatives?
I am pretty sure OAI mostly cares about their virtualization IP for MacOS. They already extensively use WSL2 for sandboxing Codex on Windows, and I imagine they want something similar for Codex on Mac.
https://github.com/scipy/scipy/issues/24990
https://www.postgresql.org/message-id/3ydjipcr7kbss57nvi67no...
Edit: TIL “Apple makes up 89% of the company's revenue in 2025”
I’m happy for the founders, they’re great folks. I contributed to CirrusCI a bit in the past and it was a great experience. I even advocated for Cirrus in a couple of my last $DAYJOBs (with varied success). Congrats Fedor!
I’m very sad they’re shutting down, though. IMHO CirrusCI was very close to a perfect CI system (I wrote a blogpost about it [0]). I’ll now have to find something to replace it with in my personal projects. I guess I’ll run their cirrus-cli in GitHub Actions for a while. But GitHub Actions is really poor. I heard some good things about Buildkite.
Having tried many other CI systems, all of which ultimately turned out to be subpar, it makes me incredibly sad to discover only now that Cirrus CI is (was?) quite a bit better than them. :( Thanks for the blog post, though!
> In 2022, we built Tart, which became the most popular virtualization solution for Apple Silicon, along with several other tools along the way.
from Tart's github:
> [Tart is for] macOS and Linux VMs on Apple Silicon to use in CI and other automations
My (naive?) hypothesis is this kind of expertise is why OpenAI chose to acquihire.
That said, I've been free-riding on tart because they've often surfaced issues I needed to address. Free riders like me are possibly the reason these companies can't make their own way.
"Hey guys, make our agents verify tool use before responding to the user. See you in 2 months. Here's 2$b"
Long term: they now have experienced dev(s?) to build their next products and features
Defaulting to throw-away-VMs for everything is also the right choice for something where the threat model includes attackers submitting patches/PRs. I'll never understand why folks were ok with just container separation for that (and often have no separation in runners).
@sama if you need someone to buy to implement timers for ChatGPT I’m your guy - my price is 2 billion dollars.
It certainly makes the idea of a career progression / promotion more challenging than it used to be, but perhaps it also opens up some new opportunities. It becomes far more "high stakes" since you have to take the risk of starting and running a startup that ultimately fails if it does not get acqui-hired.
This has been popular for 25+ years. Likely before, but that's when I first started noticing a significant number of companies that were clearly in business solely TO BE BOUGHT.
Today we use Hertzner and OVH and roll out our own solution whenever possible.
Running lean and mean.
Depending on such third party services is a trap.
Self hosting is the way to go if you need to keep monthly services spend as low as possible but you have extra time to spend, such as with a hobby project.
Whenever I’ve worked on real startup projects, self-hosting became a constant source of little tasks for the engineering team to mix into our weekly workload. There were always little tasks to upgrade this service, investigate why that one server was slow, or to migrate something to a bigger server because we were bottlenecked on some resource. Then we had to manage backups and do our recovery drills, along with changing the backup strategy every 6 months because someone had a better idea.
When we started to add up all of the time spent managing everything it starts to look like spending dollars (of engineer time) to save pennies on SaaS bills.
Probably not a popular thing to say on HN, but I now try to stay away from teams that go to extremes to self-host everything because I just want to get my work done, not also be constantly involved in running the underlying services. I do it for my own hobby projects at home but I don’t want to be doing it at work where we have money to spend to lighten the load. If the cost is the occasional migration to a different 3rd party service that’s not a big workload relative to everything involved in self-hosting.
We did not have any budget constraints at all.
Depending on 3rd party meant:
1. Begging for issues where project owner has marked them "won't fix"
2. Navigating hundreds of features we don't use, don't need and not having features we absolutely need but they don't have.
3. Weird gotchas and cost saving implemented by them, where we do not want to save any money.
>When we started to add up all of the time spent managing everything it starts to look like spending dollars (of engineer time) to save pennies on SaaS bills.
We actually factored all costs, our self hosted solution are "very lean" and still come out ahead when you factor in time/cost.
>spending dollars (of engineer time) to save pennies on SaaS bills.
I ran by this for long time fasely believing "engineers are way more expensive than cloud bills, so these thousands of dollars we are spending on these services don't matter"
but when we actually got down to fixing all , we realised now it costs us 1/10th of what it used to with more flexibility and reliability.
>Probably not a popular thing to say on HN, but I now try to stay away from teams that go to extremes to self-host everything because I just want to get my work done, not also be constantly involved in running the underlying services
we found exact opposite tbh, integrating into others hurt our performance, wasted our time, made us frustrated and desperate.
Only external service we use now are Anycast for serving our sub millisecond api and "billing", yes billing because it has lots of edge cases, taxes and all wicked things we can't manage on our own.
Still looking to rollout inhouse biller soon though.
- gitea
- woodpecker CI
- my own docker registry
- portainer running on my docker swarm
Cost savings are insane and the speed of latest amd epycs are miles ahead of the default ci instances on github and other places.
I wish Fedor and everyone at Cirrus the best of luck and OpenAI and thank them immensely for the years of free CI they gave to us in the Pony programming language despite it not having any marketing value to them.
So they want an integrated solution with CI, Python packaging and vibe coding.
That is a $100 million valuation at best, not a $1 trillion one.
Proceeds to buy white collar workers.
orchestration
docker / virtualization framework is for one machine
this stuff is for 100s - 1000s machines
> We never raised outside capital
I guess it worked out though
https://developers.openai.com/api/docs/guides/tools-computer...
I noticed on Altman’s recent announcement about someone being mean to him, he said that OpenAI had “changed the world” - conspicuously lacking any mention of “better”.
Can you talk a bit more about your journey without raising funds?
Also what does HN think of that path today when trying to launch a new AI startup?
It was hard and I was lucky with my previous pre-IPO gigs at Airbnb and Twitter so I had some bootstrap fund. In retrospective a dev tools startup in 2017 with no network and no VC support was a crazy idea but I was young and didn’t think thought too much.
Then it was long 8 years of raw work and constant questioning this choice. Then finally a third component: luck. In 2024-2025 it kind of grew organically due to market changes and back in October 2025 I finally stopped questioning the future of Cirrus Labs.
My only advice if I may, try to get your first dollar from your startup while you are employed.
I am too late for that as I am full time but also lucky to have had a previous exit.
I am planning to go the VC route this time, because the problem I am going after feels VC size.
However I feel bootstrap or small F&F round gives you more flexibility when it comes to exits.
Congrats again!
We've shared a few customers over the years, and we have an increasing number of folks moving over after this change.
Feel free to drop me a note at hugo at namespacelabs.com to chat about it.
Do service providers not think customers have other things to do than simply maintain their existing infrastructure?
Plus migration is super easy with Cirrus CLI -- tool to run our CI task definitions locally or in any CI. See https://github.com/cirruslabs/cirrus-cli
> We are no longer accepting new customers for Cirrus Runners but will continue supporting the service for existing customers through their existing contract periods.
This is the risk we run when we get services from companies that aren’t Microsoft, IBM, etc. (I would say Google but LOL, they obviously kill products even faster than the startup death cycle).
We started a company to make a big difference in the world and build an engineer’s dream company, and that’s why we have now decided to do the exact opposite and become employee numbers 32,463 through 32,510 at one of the largest tech companies in the world because money is nice.
Look, I’d have done the same thing, I’m not criticizing the choice. I just think we don’t need this kind of weird unnatural rhetoric.
Please just stop with the tech industry puffery. You’re not Steve Jobs, you’re just the DevOps team at OpenAI now. You’re dumping your worthless code on GitHub, and you’re kicking your customers to the curb.
There’s no PR spin left to do anymore. You’re not a company anymore and you’re not a founder anymore.
I’m sure there’s a way to say the same thing without coming across as a bullshitter.
Could have been a private email to customers.
For most CI use, you can choose between:
Anka, a "contact-us for pricing" closed-source projet, where you have to pay expensive license (easy 3000 USD/yr per machine)
tart, which is a lightweight wrapper around the official Apple API.
https://github.com/cirruslabs/orchard/commit/3cfa2445500f45f...
With https://khronokernel.com/macos/2023/08/08/AS-VM.html
Some people might find it very attractive:
Instead 25 Mac Mini you might need only 5.
+ No licensing to pay to Anka.
That said, I find their aqui-hire by OpenAI disappointing for a number of (mostly personal) reasons. However, I wish them the best regardless.
It's kind of like electric cars charged with electricity from coal power plants.
This just confirms to me that we are no where near AI being able to write any complicated software. I mean, if it could woudln't OpenAI just prompt it into existence? ;)
I'm guessing you're referring to this recent report of the security vulnerabilities Mythos found and submitted patches for? That just seems like they don't want the negative press and/or liability if their new model ends up being used to create 0-days that cause widespread damage.
I don't understand why these sites just put a bunch of buzzwords instead of telling you what it actually is.
What's actually happening is that AI labs have infrastructure needs that don't map cleanly onto existing commercial products, so the fastest path to having the tool they want is to bring the team building it in-house. That's closer to procurement than a traditional acqui-hire.
Whether that's net positive for the ecosystem is genuinely unclear. You get a better-resourced tool in the near term. But you also get organizational risk: if the acquirer pivots or the team gets reassigned, the institutional knowledge goes with it. Tart being relicensed more permissively is the hedge against that scenario, and it's a smart move.