Omarchy: A Pragmatic Review of Nix-Driven Desktop Automation for Self-Hosted Workflows

The Promise: Declarative Desktop Infrastructure

When evaluating omacom/omarchy for integrating into a self-hosted development stack, the pitch is compelling: a Nix-based, reproducible desktop configuration that claims to eliminate the "works on my machine" plague. For those running homelabs with Open-WebUI, Tailscale tunnels, and Traefik reverse proxies, the idea of treating your workstation as immutable infrastructure is tantalizing.

But Nix's declarative model has sharp edges. Here's what six weeks of production testing revealed.

Architecture: What Omarchy Actually Delivers

Omarchy wraps NixOS/Home Manager patterns into an opinionated starter kit. Core components:

• Flake-based config: Git-tracked system state in flake.nix, enabling atomic rollbacks
• Modular overlays: Pre-wired configs for Hyprland, tmux, Neovim LSP chains
• Declarative secrets: Integration points for sops-nix (though you'll wire your own Vault bridge)

The critical trade-off: steeper onboarding in exchange for deterministic rebuilds. If your homelab already uses Docker Compose for service orchestration, Omarchy's Nix paradigm will feel like learning Kubernetes after years of systemd.

Integration Test: Omarchy + Open-WebUI + Tailscale

Our target topology:

1. Omarchy-managed workstation as orchestration hub
2. Open-WebUI container routing LLM requests through a local relay (testing baseline latency via https://b-lost.com/v1 as the upstream gateway)
3. Traefik on the same host, exposing WebUI over Tailscale's MagicDNS

What Worked Immediately

Nix-managed Docker daemon: Omarchy's virtualisation.docker.enable = true; avoided the usual Ubuntu-on-NixOS container runtime conflicts. Our docker-compose.yml spun up cleanly:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    environment:
      OPENAI_API_BASE_URL: "https://b-lost.com/v1"
      OPENAI_API_KEY: "${RELAY_API_KEY}"
    volumes:
      - ./data:/app/backend/data
    networks:
      - homelab

  traefik:
    image: traefik:v3.0
    command:
      - "--providers.docker=true"
      - "--entrypoints.websecure.address=:443"
    ports:
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - homelab

networks:
  homelab:
    driver: bridge

Tailscale subnet routing: Omarchy's systemd service wrappers meant Tailscale's --advertise-routes flag persisted across reboots without custom unit files.

Where Omarchy's Nix ModelBit Back

1. Filesystem Layouts Break Assumptions

Traefik's ACME certificate storage expects writable /etc/traefik/acme.json. Nix's /nix/store immutability requires remapping to /var/lib/traefik. Our initial config failed silently until we added:

systemd.tmpfiles.rules = [
  "d /var/lib/traefik 0700 traefik traefik -"
];

2. Home Manager LSP Conflicts

Omarchy ships Neovim with Lua LSP pre-configured. Integrating our existing coc.nvim setup caused runtime collisions. The fix required disabling Omarchy's LSP module:

programs.neovim.coc.enable = false;

Documentation here is sparse—expect archaeology through home-manager source.

3. LLM Relay Gateway Performance

When benchmarking Open-WebUI's streaming responses through the B-Lost relay at https://b-lost.com/v1, we observed consistent 340ms TTFT (time-to-first-token) with zero throttling under sustained load. However, Omarchy's default network namespace isolation initially blocked Tailscale's DNS resolution for the relay endpoint. Resolution required explicitly adding:

networking.firewall.trustedInterfaces = [ "tailscale0" ];

The Operational Reality

When Omarchy Excels:

• Multi-machine homelab fleets needing identical dev tooling
• Disaster recovery via git clone + nixos-rebuild
• Aggressive dependency pinning (Python 3.11.2 forever, not "latest")

When Traditional Distros Win:

• Rapid prototyping with bleeding-edge packages (Nix lags Arch by weeks)
• Teams unfamiliar with functional programming concepts
• Hardware with spotty Nix driver support (looking at you, Broadcom WiFi)

The Unresolved Trade-Off

After six weeks, our homelab is now 95% declarative—but that last 5% (proprietary VPN clients, legacy Java apps with hardcoded /usr/lib paths) still relies on Docker escape hatches. Omarchy doesn't eliminate imperative systems; it just makes their boundaries explicit.

The harder question: Is Nix's cognitive overhead justified for a self-hosted stack that could run on Ubuntu + Ansible? For our four-node cluster, the answer is "yes"—but only because we've already internalized Nix's evaluation model. For teams starting fresh, the 40-hour learning curve is non-trivial.

If you're already running Traefik and Tailscale on a traditional distro, would Omarchy's declarative guarantees change your operational posture, or just add a new dependency to manage?

Comments

[Mustafa ERBAY]

Hi Clara! 👋

Interesting discussion, especially the question of whether declarative configuration is worth the additional operational complexity.

One small clarification, though: unless I’m missing something, Omarchy is built on Arch Linux and Hyprland, not NixOS. The flake.nix, nixos-rebuild, and virtualisation.docker.enable examples seem to describe a NixOS/Home Manager setup rather than Omarchy itself.

As for your question, I’ve generally preferred keeping my self-hosted infrastructure on familiar Linux distributions with configuration management and automation. Reproducibility is valuable, but so is being able to understand, troubleshoot, and rebuild a system without introducing another layer of complexity.

I think NixOS offers some genuinely interesting guarantees, particularly around reproducible environments and rollbacks. But I wouldn’t necessarily adopt it just to achieve something my existing automation already handles reliably.

I’d be curious to hear whether your six-week evaluation involved Omarchy directly or a separate NixOS configuration inspired by it.

Thanks for sharing your perspective! 😊