Garnix is shutting down [not OC]

I couldn’t find anything from <garnix.io> so quoting an email I received from contact@garnix.io:

garnix is shutting down

Hi everyone,

We wanted to let you know that garnix is joining forces with Shopify.

We are sad to announce that, as part of this transition, the hosted garnix service will shut down on July 15th 2026. But we are open sourcing the garnix codebase, available here; we hope this will help you smoothly move to using your own instance or a shared one. If you are interested in operating a public community instance, please get in touch — we’d be happy to talk.

We will also be deleting all user data on July 15th. This includes build artifacts. Be sure to download what you want to keep before then.

Thank you all for using garnix and for the feedback and support over the years. While we are excited about our next step at Shopify, we will also miss working with this community. From the very first, with generous donations in our Open Collective days and thoughtful feedback, you’ve been great.

– the garnix team (Alex David, Sönke Hahn, and Julian K. Arni)

32 Likes

Yeah, saw that. Bummed, because I finally have tweaked my Buildbot to be exactly the way I want it and keyed off my Gitea instance. And just when I complete that process, here comes Garnix dropping all of its code in an open repo dump.

It’s especially a bummer because I don’t have a Mac builder locally, but I use Garnix’s Mac builds for my home-manager on my work MacBooks and it has been fantastic for that. Alas!

3 Likes

Garnix really set the bar of “just works" CI experiences. We loved it here at Mercury and were using it for all our open source repos.

Also call-by-hash has been a really interesting mindshift for me to think about infra. I’ve been building a garnix-like deploy experience on top of lambda that I still need to release at some point lambda-nix - asciinema.org

Sad to see it wind down!

7 Likes

Congrats! Very generous to open source the code, and interesting to see a large commercial deployment of NixOS.

4 Likes

Hi,

There are many users and organisations that relied on Garnix for their nix CI, and many who saw it as a path forward from their existing nix pipeline. With Garnix now discontinuing service so soon, that leaves many in a scramble to find a solution.

Myself, @eureka-cpu and some others at Numtide are considering picking up the torch to help ensure a smooth transition to a self-hosted solution, while maintaining garnix as an open source project. Offering a SaaS is not in Numtide’s DNA, so we don’t want to hold the torch in that way.

I have prior experience with Haskell and also with Nix CI/CD from my work on buildbot-nix, @eureka-cpu has prior experience with Haskell, we both have extensive experience with Nix/NixOS.

This post serves as a poll to see if there is interest, and which features are most important to support, if there is.

If there is anyone who is unable to reply here to this posting, please reach out directly to Numtide, via hello@numtide.com

23 Likes

Since GHA is free for public repos, and I took inspiration from nixpkgs-review-gha ( GitHub - Defelo/nixpkgs-review-gha: Run nixpkgs-review in GitHub Actions · GitHub ) which a lot of maintainers use including myself, why not just run all the build jobs on GHA? That’s why I made

It has a python tool to generate build matrix and bunch of inline shell script to set commit check status just like garnix would, and push to a cache endpoint (currently tested on attic, cachix, and I’m currently debugging niks3). It also completely skips paths that’s already in cache and sets status for them (excluded jobs also have status)

Users basically only need to copy pasta a yaml file and run a few gh variables/secrets set to enable cache and you would basically have garnix for free without 2 downsides I had with it (limits to 100 jobs, does not support legacyPackages.* matching)

Free build for everyone! No need to get a big server to build aarch jobs anymore :wink:

EDIT: you can check the check status sample in the repo itself or GitHub - stepbrobd/inc: the second largest nix monorepo · GitHub. Click on the green/yellow/red dot/cross associated with a commit)

1 Like

Cool! Will need to try this out, probably a lot better than my home-grown pile of Nushell and actions.nix (especially since I want to replace it with github-actions-nix), nix-auto-ci.

How do you handle build scheduling? Say I have 2 checks that test out the same program, does it compile that program twice or does it build the program once and then the checks? This seems like the main reason to use a Nix-native CI system, as opposed to bolting it on something else.

EDIT: @mightyiam has already filed an issue about this! Avoiding duplicate builds · Issue #1 · stepbrobd/atelier · GitHub.

1 Like

Yeah I had this problem like right after trying to do a 180 job build matrix…

Since the builds are running in separate environments, and I dont want to make scheduling decisions in at matrix generation time (not sure if its even possible to order some matrix jobs after some other ones), I’m basically monitoring the situation in browser and cancel the job right after a big job builds and cache is pushed (also depends on luck, some heavy job might pick up runner earlier) and restart with cache…

The other restriction is that hosted GHA runners have 6h limit and can’t outlive that, if you have job that will go over the time limit it will never succeed (the runner spec is not bad but definitely cannot compare with 1TB RAM 80 core builders in the HPC center I work for)

1 Like

Could I use your atelier as a frontend for GitHub - lovesegfault/rio-build: Distributed builds for Nix · GitHub? Also ties in with Customizing how Nix is installed · Issue #2 · stepbrobd/atelier · GitHub. Still need to host rio-build in your K8s cluster though.

Could I use your atelier as a frontend for GitHub - lovesegfault/rio-build: Distributed builds for Nix · GitHub ?

could you elaborate a bit? do you mean using it to generate job matrix? its just a wrapper around nix-eval-jobs and output json for GHA matrix to consume:

$ nix run github:stepbrobd/atelier -- discover --workers 32 --systems aarch64-darwin,x86_64-linux
warning: unknown setting 'allowed-users'
warning: unknown setting 'keep-env-derivations'
warning: unknown setting 'trusted-users'
::notice::Discovered 10 build cells in 1 chunk(s), 0 skipped
chunks=[{"name": "Build", "cells": "{\"include\": [{\"system\": \"x86_64-linux\", \"runner\": \"ubuntu-latest\", \"label\": \"packages.x86_64-linux.mock-oidc-server\", \"installable\": \".#packages.x86_64-linux.mock-oidc-server\", \"error\": \"\"}, {\"system\": \"x86_64-linux\", \"runner\": \"ubuntu-latest\", \"label\": \"packages.x86_64-linux.default\", \"installable\": \".#packages.x86_64-linux.default\", \"error\": \"\"}, {\"system\": \"x86_64-linux\", \"runner\": \"ubuntu-latest\", \"label\": \"packages.x86_64-linux.niks3-server\", \"installable\": \".#packages.x86_64-linux.niks3-server\", \"error\": \"\"}, {\"system\": \"x86_64-linux\", \"runner\": \"ubuntu-latest\", \"label\": \"packages.x86_64-linux.niks3\", \"installable\": \".#packages.x86_64-linux.niks3\", \"error\": \"\"}, {\"system\": \"x86_64-linux\", \"runner\": \"ubuntu-latest\", \"label\": \"packages.x86_64-linux.niks3-hook\", \"installable\": \".#packages.x86_64-linux.niks3-hook\", \"error\": \"\"}, {\"system\": \"x86_64-linux\", \"runner\": \"ubuntu-latest\", \"label\": \"packages.x86_64-linux.niks3-tests\", \"installable\": \".#packages.x86_64-linux.niks3-tests\", \"error\": \"\"}, {\"system\": \"x86_64-linux\", \"runner\": \"ubuntu-latest\", \"label\": \"packages.x86_64-linux.rustfs\", \"installable\": \".#packages.x86_64-linux.rustfs\", \"error\": \"\"}, {\"system\": \"x86_64-linux\", \"runner\": \"ubuntu-latest\", \"label\": \"packages.x86_64-linux.benchmark-closure\", \"installable\": \".#packages.x86_64-linux.benchmark-closure\", \"error\": \"\"}, {\"system\": \"x86_64-linux\", \"runner\": \"ubuntu-latest\", \"label\": \"packages.x86_64-linux.niks3-docker\", \"installable\": \".#packages.x86_64-linux.niks3-docker\", \"error\": \"\"}, {\"system\": \"x86_64-linux\", \"runner\": \"ubuntu-latest\", \"label\": \"devShells.x86_64-linux.default\", \"installable\": \".#devShells.x86_64-linux.default\", \"error\": \"\"}]}"}]
skipped=[]

my answer is this is basically useless outside of atelier

regarding customizing how nix is installed, i plan to make it either use the provided installer action, or allow user to provide arbitrary installer script

Like using it as a remote builder. Do you have plans to support remote builders? Also could use like https://nixbuild.net/. So atelier would do Github-side things and it would just send builds to Rio via --store or something in nix.conf (sorry, I don’t know much about remote builders).

Adding remote builder would allow you to use rio-build, but the problem is the config surface

if you are fine with me adding another arbitrary shell script entry to allow users configure secrets for remote builders, then its fine with me (i dont want to expose too may config knobs cz there are already a ton for push targets), and i would probably also default max-jobs to 0 if this script is non empty (tbh i think remote builder support kinda defeats the purpose, i made this because i dont have powerful build machines for aarch builds for both linux and darwin, and i dont want to pay as a brokie, so GHA on public repos is the solution)

1 Like

Same really.

Just throwing out random ideas I thought would be nice to have (as an aspiring k8s self-hoster, once I get a new laptop to replace my current one I was thinking I could set up k8s on the old (current) one). It’s fine if you think remote builders are out of scope for your project, it is your project.

I am interested to see Garnix continue to live as a self-hostable option, with ever improving docs and simplicity to deploy! I like its interface far more than Buildbot which looks like it’s straight out of 1999 (No offense to buildbot-nix, that integration is great. It’s Buildbot itself that has bad UX)

Willing to help out, for sure!

1 Like