[snowpalmer]

I agree that removing the container would be better on resources.

However, most self-hosted software is already "pre-packaged" in Docker containers. It's much easier to grab that "off-the-shelf" than have to build out something custom.

[pxc]

> However, most self-hosted software is already "pre-packaged" in Docker containers. It's much easier to grab that "off-the-shelf" than have to build out something custom.

Imo, the quality and documentation level of an application's build system is a valuable signal in determining its overall health and competency. It usually (though not always) ends up being that well-maintained software written for modern runtimes is very easy to build from source and run. Even if I do end up using the developer's container image, I generally want to check out their manual deployment documentation.

[transpute]

NixOS improves the reproducibility of both self-hosted software and configuration state.

[kkfx]

In NixOS/Guix System there is no need of such package, the configuration language/package manager takes care of anything, configuration included.

Let's say you want Jellyfin?

    jellyfin = {
      enable = true;
      user="whatyouwant";
    }; # jellyfin

under services and you get it. You want a more complex thing, let's say Paperless?

    paperless = {
      enable = true;
      address = "0.0.0.0"; 
      port = 58080;
      mediaDir = "/var/lib/paperless/media";
      dataDir = "/var/lib/paperless/data";
      consumptionDir = "/var/lib/paperless/importdir";
      consumptionDirIsPublic = true;
      settings = {
        PAPERLESS_AUTO_LOGIN_USERNAME = "admin";
        PAPERLESS_OCR_LANGUAGE = "ita+eng+fra";
        PAPERLESS_OCR_SKIP_ARCHIVE_FILE = "with_text";
        PAPERLESS_OCR_USER_ARGS = {
          optimize = 1;
          pdfa_image_compression = "auto";
          continue_on_soft_render_error = true;
          invalidate_digital_signatures = true;
        }; # PAPERLESS_OCR_USER_ARGS
      }; # settings
    }; # services.paperless

Chromium with extensions etc?

    chromium = {
      enable = true;
      # see Chrome Web Store ext. URL
      extensions = [
        "cjpalhdlnbpafiamejdnhcphjbkeiagm" # ublock origin
        "pkehgijcmpdhfbdbbnkijodmdjhbjlgp" # privacy badger
        "edibdbjcniadpccecjdfdjjppcpchdlm" # I still don't care about cookies
        "ekhagklcjbdpajgpjgmbionohlpdbjgc" # Zotero Connector
        # ...
      ]; # extensions
     
      # see https://chromeenterprise.google/policies/
      extraOpts = {
        "BrowserSignin" = 0;
        "SyncDisabled" = true;
        "AllowSystemNotifications" = true;
        "ExtensionManifestV2Availability" = 3; # sino a 06/25
        "AutoplayAllowed" = false;
        "BackgroundModeEnabled" = false;
        "HideWebStorePromo" = false;
        "ClickToCallEnabled" = false;
        "BookmarkBarEnabled" = true;
        "SafeSitesFilterBehavior" = 0;
        "SpellcheckEnabled" = true;
        "SpellcheckLanguage" = [
                           "it"
                           "fr"
                           "en-US"
                         ];
      }; # extraOpts
    }; # chromium

Etc etc etc. You configure the entire deploy and get it generated, a custom live? With auto-partitioning and auto-install? Idem. A set of hosts in a network similar (NixOps/Disnix) and so on. The configuration language do all, fetching sources and build if a pre-built binary is not there, setting up a DB, setting up NGINX+let's encrypt SSL certs, there are derivation (package) per derivation options you can set, some you MUST set, defaults etc., it's MUCH easier than anything else, only issue is how many ready-made derivations are there, and in packaging terms Guix is very well placed, NixOS is more than Arch, even if something will be always not there or incomplete as long as devs do not learn alone the system and start using Nix/Guix also to develop, so deps are really tested in dedicated environments and so on, and users always get a clean system, can change and boot in a previous version and so on.

[stackskipton]

Sigh Nix users.

I need to run uptime kuma, Here is Docker Compose: https://github.com/louislam/uptime-kuma/blob/1.23.X/docker/d...

What is equivalent in Nix?

[zarzavat]

Nix/NixOS and Docker work in fundamentally different ways so you have to decide which method of operation is most suitable for your use case.

If you use Docker then each container requires its OS image, which is fine if you’re running on a server and running other people’s software, but if you want to develop your own containers on a laptop then that convenience becomes an inconvenience. Nix is more lightweight.

[pxc]

Support for uptime-kuma is built into NixOS and documented here: https://search.nixos.org/options?channel=24.05&from=0&size=5...

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?

[kkfx]

    services.uptime-kuma = {
      enable = true;
      appriseSupport = true;
      settings = {
        ...
      } # settings
    };

These are examples, you have to write down the system configuration, meaning picking uptime-kuma, choose what deps you want and so on. No need to "run a oneliner" on a homeserver than ssh and do things by hand to tweaks, with no reproducibility or hoping someone else have already made them in something ready-made.

Doing the pick-a-oneliner is a classic developer in Silicon Valley mode move which cause a classic set of disasters, like wasting gazillion of resources for nothing, not seen an image with someone else ssh authorized key, keep running vulnerable software and so on because he/she just need a oneliner, no matter if it pull down 10 images, consuming 1Tb of storage, having stellar CPU requirements etc because you are in SV-mode, you do not care and anyway you do not pay for the iron because it's a company one or it's a cloud service you do not even see how much loads you generate, AWS bill will go to someone in accounting. On the other side of course IT business like that, because they can sell you a ready made image, selling just few line of code can't be priced much, while selling a service who provide a big file set might be priced well. Also selling a VPS and so on "hey devs, you literally just need to click here and we do the rest" pay very well. Those who sell of course. Aside such mindset create an enormous amount of layers who in the long run create so heavy and complex infra no one knows them.

Just try to see what Home-assistant do. By default their devs suggest to run it on a dedicated machine (!) so they imaging you buy a single-board computer juts to run a damn app, ending up with this model with a gazillion of single board computer scattering around. Second option containers. So to run HA you need let's say 1-3Gb of stuff, nearly no mention to the simplest pip install. Zero mention that unlike pip install NixOS does not need to download a gazillion of binary basic stuff for python deps, if you have them on your /nix/store you just link them on as many pkgs needs them, keeping just one copy.

In the end you craft your system, as a single application, a single configuration, which demand 1/10 of resources used otherwise, have much less thing who can breaks, it's easy to know entirely etc.

You might state that's a classic operation vs devs.

[Arelius]

I mean, I don't know what that is, but looking at the documentation, it should be something like:

  config = {
    services.uptime-kuma = {
      enable = true;
      settings = {
        PORT = 3001
      };
    };
  };

[kkfx]

It's a node.js web-app, so it might need some NGINX (or other web server) settings, eventual acme/let's encrypt etc, few SLoC to customize and that's the very point: being able to customize anything without two-stage with one by hand in a terminal or with separate tools like Ansible.

[Arelius]

Yeah, none of those seem to be covered in the parent post, so the Nix example is equally simplistic.