As to your question: on NixOS there's no need to fuck around with volume mounts or port forwards or specifying a source image or explicitly setting a restart policy, so the majority of what is defined in that file, which is pure boilerplate, disappears. And that docker-compose file doesn't configure any non-default settings or install any optional dependencies, so all you're left with for the NixOS equivalent is:
services.uptime-kuma.enable = true;
so about 0.1x the amount of configuration as appears in that docker-compose.yml file.
But imagining for a moment that NixOS didn't already have built-in support for running uptime-kuma as a service, or even include uptime-kuma in its package repositories, I would still prefer to deploy it on NixOS, if I were deploying it for self-hosting purposes. Chasing the docker-compose.yml files of others is like distrohopping. The distrohopper bounces aimlessly from one operating system to another, his choice of fundamental operating system tools dictated to him by a string of out-of-the-box experiences which are determined by a complex enough confluence of factors that they are significantly random. When his distrohopping solves a problem, it causes another one, and his mode of engagement guarantees that neither problem is a thing he'll ever understand or have real control over.
Unlike the distrohopper, the distrochooser is patient. She is willing, when needed, to RTFM. For the price of learning how the software she runs is operated, and how the separate programs and libraries included in her OS fit together to form a stack, she is free. The distrochooser can run any Linux distro she wants, because she knows how to bring over whatever tools she needs. As a result, she has an opportunity that the distrohopper does not: the opportunity to choose basic tools— a package manager, an operating system, a deployment method, a configuration management system— based primarily on technical merits.
In so much of our lives, and perhaps especially our professional lives, we don't use the tech we use because its good. We don't use it because it's fun, or pleasant, or even reliable. We use it because it's bundled; the company already paid for it. Or we use it because of network effects: some application expects it, or it's the only platform some compliance-mandated tool supports, or its file format is widely abused for interchange because the vendor is a monopolist. Or we use it because it's the thing we already know and we're on a tight deadline.
Hobby computing is special. It's a context where there is actually room to choose our software for virtues that are intrinsic to it, or for reasons that are personal to us. Where we can choose tech just because it is beautiful, or because it was made by a friend, or because it feels good to use, or because it respects our freedom. To shrink our horizons when the code is transparent and freely available, when mastery is right there for the taking by anyone who wants it, is to erase one of the vital differences between the kind of computing that personal self-hosting is and corporate computing. It's a terrible waste.
I want to use NixOS because the iteration loop for working with it is fast, safe, predictable, and ultimately very satisfying. I want to use NixOS because it at least attempts to solve fundamental problems of building and distributing software that container-based solutions just punt on. I want to use NixOS because the interfaces it offers for managing services are outstandingly flexible and feature-complete. Why would I just surrender to worse-is-better, to network effects, to incidental bullshit— and give all of that up— when I can just roll up my sleeves and write the frickin' NixOS module? I can run whatever applications I like *and* run it on an OS I like, managed by tools I like. So why the hell wouldn't I?
As to your question: on NixOS there's no need to fuck around with volume mounts or port forwards or specifying a source image or explicitly setting a restart policy, so the majority of what is defined in that file, which is pure boilerplate, disappears. And that docker-compose file doesn't configure any non-default settings or install any optional dependencies, so all you're left with for the NixOS equivalent is:
so about 0.1x the amount of configuration as appears in that docker-compose.yml file.But imagining for a moment that NixOS didn't already have built-in support for running uptime-kuma as a service, or even include uptime-kuma in its package repositories, I would still prefer to deploy it on NixOS, if I were deploying it for self-hosting purposes. Chasing the docker-compose.yml files of others is like distrohopping. The distrohopper bounces aimlessly from one operating system to another, his choice of fundamental operating system tools dictated to him by a string of out-of-the-box experiences which are determined by a complex enough confluence of factors that they are significantly random. When his distrohopping solves a problem, it causes another one, and his mode of engagement guarantees that neither problem is a thing he'll ever understand or have real control over.
Unlike the distrohopper, the distrochooser is patient. She is willing, when needed, to RTFM. For the price of learning how the software she runs is operated, and how the separate programs and libraries included in her OS fit together to form a stack, she is free. The distrochooser can run any Linux distro she wants, because she knows how to bring over whatever tools she needs. As a result, she has an opportunity that the distrohopper does not: the opportunity to choose basic tools— a package manager, an operating system, a deployment method, a configuration management system— based primarily on technical merits.
In so much of our lives, and perhaps especially our professional lives, we don't use the tech we use because its good. We don't use it because it's fun, or pleasant, or even reliable. We use it because it's bundled; the company already paid for it. Or we use it because of network effects: some application expects it, or it's the only platform some compliance-mandated tool supports, or its file format is widely abused for interchange because the vendor is a monopolist. Or we use it because it's the thing we already know and we're on a tight deadline.
Hobby computing is special. It's a context where there is actually room to choose our software for virtues that are intrinsic to it, or for reasons that are personal to us. Where we can choose tech just because it is beautiful, or because it was made by a friend, or because it feels good to use, or because it respects our freedom. To shrink our horizons when the code is transparent and freely available, when mastery is right there for the taking by anyone who wants it, is to erase one of the vital differences between the kind of computing that personal self-hosting is and corporate computing. It's a terrible waste.
I want to use NixOS because the iteration loop for working with it is fast, safe, predictable, and ultimately very satisfying. I want to use NixOS because it at least attempts to solve fundamental problems of building and distributing software that container-based solutions just punt on. I want to use NixOS because the interfaces it offers for managing services are outstandingly flexible and feature-complete. Why would I just surrender to worse-is-better, to network effects, to incidental bullshit— and give all of that up— when I can just roll up my sleeves and write the frickin' NixOS module? I can run whatever applications I like *and* run it on an OS I like, managed by tools I like. So why the hell wouldn't I?