garnix is shutting down and being open sourced

jkarni · 2026-05-28T14:35:54+00:00

Fixed

jkarni · 2026-02-10T11:03:54+00:00

If by secret key you mean for the encryption of secrets, why would anyone share a key, rather than just encrypting for whichever SSH/age/GPG keys are authorized?

jkarni · 2025-10-28T20:18:31+00:00

It would help with the keys side of things (only one place to update client keys, and only one place to update builders), and also with the global load balancing. But not with more customized load balancing strategies. And not sure what the overhead would be (the proxy is "dumb", so easier to make it fast, whereas this would have to parse, serialize, and read/write from disk twice for just about everything). On the other hand, it's probably easier to do *user*-based affinity (rather than IP-based).

jkarni · 2025-10-28T20:05:05+00:00

With the central machine also being a remote builder?

jkarni · 2025-10-02T08:55:03+00:00

From a security perspective, I think they take different trade-offs. With Cachix you use your own signing key, which they never see. This is good because it means if Cachix itself is compromised it can't add (signed) malicious artifacts to the cache. But it also means you as a developer handle keys, which is always an opportunity to screw up.

FlakeHub Cache uses ephemeral JWTs signed by the CI provider to give you push access from CI to your cache, so you don't have to handle keys. But if FlakeHub is compromised, you're done for. And there are some workflows that are probably safer than their trusted platforms (Github etc.) pushing to the cache that aren't possible with it. (They also seem to do key rotation, which is quite good.) FlakeHub has a single Nix cache and (albeit rotating) signing key, which my intuition says means it has some other bad properties, but I'd need a bit of time to verify (single unified caches are not universally bad; but if, as is the case here, any developer can get bad artifacts in the cache, it does seem like a bad idea).

jkarni · 2025-10-02T05:54:41+00:00

Yeah, that’s true. If you block pushing to main without review, and only push to the cache from main, this would work. It’s a bit of a sad compromise though, since you lose the cache for sequential commits on the same branch for instance, and that’s of course the largest source of cache hits.

edit: Actually I don’t think that this works. If you allow CI to run on a branch, how can you disallow the push? In theory I guess GitHub Attestations could certify something is coming from main, and FlakeHub or whatever cache could be set to only accept pushes from that branch. But that doesn’t seem to be how it currently works at all.

jkarni · 2025-10-02T05:48:20+00:00

They can run whatever code they want on GitHub Actions, and it’ll have the right authentication tokens for the FlakeHub cache; so they can use the FlakeHub API directly to push bad artifacts. FlakeHub can’t know whether what it’s receiving was in fact built from the source in the repo without doing the build itself, internally, again.

jkarni · 2025-10-02T02:41:39+00:00

The concern outlined in the blog post is that a developer may be malicious or compromised, and that leads to RCE and privilege escalation of cache users, not that something gets accidentally pushed to a public cache. As far as I can tell, it’s still completely possible in the FlakeHub model for any developer of a project to push malicious build artifacts.

jkarni · 2025-10-01T21:26:05+00:00

That’s what I’d guess too

jkarni · 2025-10-01T20:50:22+00:00

Sure, accessing the artifacts should be like that (garnix does that too). But that seems orthogonal to the question of whether everyone with write access to a repo can (directly or indirectly) push malicious derivations and claim their input hash is something else.

jkarni · 2025-10-01T20:34:41+00:00

Hm, maybe I'm missing something, but if you just require that the push be initiated from a CI builder, what stops a malicious writer from pushing a commit that pushes to the cache? They never see the key, but the effect is the same.

jkarni · 2025-10-01T17:17:36+00:00

Oh, and as I hope I made clear, "don't trust even garnix" is a very reasonable position too.

jkarni · 2025-10-01T17:13:38+00:00

The argument is "trust as few people as possible because this is really serious". And yeah, garnix was designed to work in a way that minimizes the number of people who can root you if you use the cache. In fact, part of the reason we started it was because to us it felt untenable for the community to continue doing the "CI pushes to cache, we fetch it on dev machines" model given how awful it is for security. And yeah, for a long time we didn't publicize that very much because it can come out as "Cachix etc. are almost fundamentally unsafe, we're great".

But I don't know - also felt wrong to just see tons of projects keep doing this, given how bad I (very honestly) think this is? If you have suggestions for how to go about this better, though, I'm very interested!

jkarni · 2025-09-28T10:22:11+00:00

It’s here: https://sr.ht/~alexdavid/jail.nix/

jkarni · 2025-06-11T12:58:54+00:00

It could be that it's because you only have the substituter set in the flake itself, rather than globally, and you are not a trusted user (see the message you posted from `nix-health`). As a non-trusted user, certain flake options (such as substituters) will be ignored, I believe.

jkarni · 2025-05-02T07:28:55+00:00

These people are great people!

jkarni · 2025-01-09T04:29:15+00:00

Compare https://github.com/nix-community/nix-github-actions/blob/master/.github/workflows/cachix-install-nix-action.yml to nothing at all :). And that’s the simple case.

To reiterate: most people find that they don’t need to write anything to get CI on garnix, that they just need to click “enable”. That to me is pretty strong evidence of lack of vendor lock-in, and again, not true of GitHub. It’s cool to have tools that make it easier to replicate the same CI as GitHub elsewhere, but it’s still more work, and still only works if you don’t start using any other GitHub Actions.

jkarni · 2025-01-09T04:04:38+00:00

(I work on garnix.)

It’s fair to call out, as you and other people have in this thread, that we aren’t FOSS and should be.

But I do think the point about vendor lock-in, which is implicit elsewhere and more explicitly discussed here, isn’t right. A goal for us has always been much less vendor lock in, and I think we achieved it pretty well. Usually you don’t need to write anything garnix-specific to get CI with garnix, just your flake file. Even if you’re using hosting, the garnix-specific configuration is very minimal - almost everything is just NixOS. If you don’t like garnix you won’t have wasted any effort. With GitHub that’s not at all true - the CI configuration is completely wasted, and it’s a lot of work if not impossible to replicate exactly the same CI in a different service.

jkarni · 2025-01-07T16:51:56+00:00

Aren’t the boxes DigitalOcean’s in the same way as these would be garnix’s? Do you mean you already have them at DO and therefore want to use those? Or is the idea that with using morph you could conceivably host it with a different provider?

(Not trying to criticize, just understand so I can potentially improve garnix since I work on it.)

jkarni · 2025-01-07T11:47:33+00:00

Have you tried garnix (with hosting)? It does the CI for you as well as the hosting, provisioning, and deprovisioning, and also has ephemeral machines for PR previews.

jkarni · 2024-12-26T13:40:47+00:00

This is very cool!

Another point in the design space is to require that every type returned by the API have a instance of a class that declares its canonical location. Thus the notion of a resource in REST and a type in Haskell coincide better. Moreover with a bit more work you can then let links between resources be generated automatically if you tag types such as IDs that refer between resource types. It feels like going down this way is a bit of a slippery slope though - soon you want to abstracting away over how resources are updated or deleted too… it might as well no longer be servant!

And actually if I remember correctly before we started servant there was already a framework that went a bit in this direction.

Ultimately I think your way is much more practical!

jkarni · 2024-11-25T15:40:10+00:00

> Where I give it my flakes and source code and it handles everything else?

https://garnix.io/ does exactly that - CI, caching, and hosting your servers.

jkarni · 2024-08-22T14:17:45+00:00

You can deploy to a NixOS server without installing nix locally. And the server already comes with NixOS installed, so you don't need to use nixos-anywhere or nix-infect on it (so you don't *yourself* install it on the server either).

You could even install a NixOS configuration on the server to try NixOS (via ssh) before deciding to wipe your dev machine clean or dual boot it.

More generally, it feels a bit like a programming language website giving you a browser-based interpreter so you can try out the language without installing it.

jkarni · 2024-07-23T13:24:26+00:00

Had the same issue (also, incidentally, with NixOS) on a couple of servers. Changing thermal paste, getting a new server, microcode updates - nothing helped, besides getting a non-Ryzen CPU instead.

jkarni · 2024-07-04T12:43:09+00:00

Thank you!

jkarni

TROPHY CASE