the awful.systems server cluster runs on an open infrastructure based on NixOS and Nix flakes, and though it desperately needs cleanup in some places, it’s still a pretty good example of how to use a Nix flake to deploy NixOS in production. feel free to browse the repo and ask any questions about how it works, or about Nix in general!
also, if I get hit by a bus, this can be used to redeploy awful.systems elsewhere. an existing admin who isn’t in the hospital or the grave can import a database backup and get back up and running!
and as always, contributions are welcome.
You must log in or register to comment.
In the car on the way home from vacation but as someone in need of a rebuild of some of my home infrastructure and have been curious about NixOS. Thanks, and thanks for the work here, I appreciate a small sliver of sanity in this insane world.
there should be some good stuff in the awful.systems repo for you! I use the same techniques to deploy NixOS to a mix of servers, desktops, and embedded systems in my home. specifically I can recommend writing your own deployment scripts that use nixos-rebuild and using sops-nix for secrets — I use it all over the place for awful.systems, but for my home network it mostly keeps wifi passwords encrypted for some of my embedded devices.
definitely let me know if you need some gentler introductory resources for Nix and NixOS too! I’ve got a few links saved up that I can recommend.
Wow, thank you so much. I haven’t touched Nix yet but I’m a greybeard systems engineer with familiarity of many distros so hopefully it won’t be too baffling (then again, I never got Gentoo successfully installed).
I will check out the repo as soon as I’m home, and thanks for the secrets info, one of the things on the top of my list.
no problem at all! here are a couple of the resources I mentioned by the way:
- Zero to Nix is a good overall guide
- nix.dev is a great cookbook-style resource that starts by explaining Nix as a programming language and expands on its concepts from there
Strangely, it seems like none of the comments from /c/freeasm have federated to lemm.ee. Is this intentional to minimize the risk of drive-by toxicity, or is this some Free Jank, not from concentrate?
EDIT: I see that my comment has federated inward, so jank it is!
this might be an activitypub breakage on our end or theirs, or maybe just the queue getting stuck. if this doesn’t clear up on its own, I might send an email to a lemm.ee admin and see if they can give it a kick
Explanation for the jank: I tried to read /c/freeasm without subscribing to it, so it didn’t federate. Classic PEBKAC.
deleted by creator
I hope you know that your hard work is appreciated. A project with this kind of scope is a lot to take on, but it’s a candle in the (very dumb) dark.
I appreciate the support! awful.systems is an amazing community, and I’m excited to see how it’ll grow from here.
Cool, thanks for releasing the source.
Curious if anyone is using Nix and NixOS in production outside of personal projects. I’ve been dabbling in it and it would solve some problems well, but I’m cautious about inflicting Nix upon anyone who isn’t already at least attracted to the Nix mindset.
You have to be a particular type of insane (which I am, not a bad thing) to go all in on Nix, and I’m interested in how that pans out in a team environment where not everyone is a Nix enthusiast. How is onboarding, turnover, velocity etc.
edit: I’m also curious about deployment and costs of running this Lemmy instance are like. What’s the stack look like when deployed, what are the monthly ingress/egress, how much CPU time does it use, etc.
of course!
you’re definitely right about needing to be a particular type of insane for Nix to fully click, and I’ve seen enough people bounce off of it that I try to make Nix optional (but very nice to have) wherever I can
with that said, there are a few areas where what Nix does is irreplaceable. broadly, areas like deployments (devops), embedded development (where Nix’s methods of cross compilation and target configuration are much saner and more reliable than average), and developer tooling are where it’s extraordinarily difficult to replicate what Nix provides, and those are also the areas where I’ve personally seen the most production usage of Nix.
I don’t personally coordinate a professional team that uses Nix, but it might be worth looking up impressions from companies that do. to my memory, two companies I know use Nix heavily are Pololu Robotics and replit (which uses Nix as a user-facing part of their developer tooling; fair warning though, last time I looked they were heavily enshittifying and pushing a bunch of AI shit).
Is there a reason you define one NixOS module each for Lemmy dev/staging/prod? Why not just have one module and take an “environment” enum option?
my reasoning at the time was:
- I was in a hurry
- I didn’t know how much the environments would differ, so I wanted to retain as much flexibility as I could get
the most likely future for those modules is that they’ll end up replaced by a module exported from the Lemmy flake, which’ll provide a set of options to configure multiple environments. that should clean up some of the messiest parts of the configuration, and it’d allow us to import different versions of the flake for each environment. it’d also keep the module in sync with the specific version of Lemmy it’s configuring, which is very nice to have.
