At the same time I’ve taken the leap into the undeniably funky realm of running an LLM as a persistent virtual assistant. This post introduces my new Groundhog project. It’s an extremely thin orchestration layer, defined at the systemd level in a 200-line Nix module.

The State of Play

I held out for a long time on adopting harness-powered workflows. I preferred high-granularity manual control offered by Zed. This gave me ways to control

• cost. My token spend was a few dollars per month, even with (to me) heavy usage.
• outcome. (model quality) x (harness quality) was simply not at a threshold where I’d have a successful outcome.

However, the tooling evolved out from under me, and I’ve had to thoroughly rebase my assumptions. The two forcing factors were:

1. My preferred Zed workflows were deprecated. The Text Thread feature was removed in favor of agent-only structure.
2. the Claude Code harness evolved, eventually addressing all of my gripes and achieving high success rates with the same models.

Additionaly, Claude Code authentiates with a Pro account and I’ve never run up against limits. Thus I’ve finally arrived at the common consensus that you simply can’t beat Claude Code as a driver. I have ceased to struggle and joined the Borg, like in The Star War.

Autonomy

I’ve felt a twinge of FOMO at autonomous agent projects like OpenClaw. Of course I want a little digital assistant looking out for my interests, keeping tabs on things I care about and pinging me when I need to know something.

There’s one big problem: None of these projects has ever come remotely close to my comfort zone to run or interact with.

There’s a tendency to bloat, especially once you get these things working on themselves. You expect me to install this app that’s 15,000 lines written in some wretched goblin language like Python or Javascript? You must be getting out of town.

Obsidian workflows

I’m a longtime pre-AI user of Obsidian. I self-host with syncthing to keep notes synced between my phone and computers. In my day-to-day work I naturally fell into a workflow that some have dubbed the “Second Brain” system. It’s the logical conclusion of both

1. Managing your own knowledge base and
2. Creating context for AI agents.

It just involves an extra step for the agent. Here’s a few simple examples of prompts for Claude Code, where I have an Obsidian vault sitting at ~/o

Read the design document at ~/o/topic/design.md. Investigate the codebase and update the document with any potential blockers. Create a plan.md with a step-by-step breakdown.

Execute on step 1 of ~/o/topic/plan.md.

Essentially you want to keep a durable view of reality that’s shared by consensus across agent sessions. Nobody needs to juggle sessions and figure out which chat to resume.

Groundhog

Anyways, all this is to say that these 3 facts came together:

1. Claude Code is now good enough to do anything
2. I appreciate a graph-based (as opposed to linear) approach to managing durable knowledge
3. I’d like to give my system a little more autonomy

This is a problem that’s solved at the systemd level with a few lines of Nix. The groundhog module definition slots into my VPS config like this:

inputs.groundhog = {
    url = "github:roriholm/groundhog";
};

services.groundhog = {
  enable = true;
  tokenFile = "/etc/groundhog/oauth-token";
};

An initial vault gets bootstrapped and registered with Syncthing. Then there’s simple logic:

1. A note syncing to the /inbox folder triggers a Claude Code instance.
2. The CC instance has access to the vault and is instructed to drain the inbox to end the wake cycle.
3. A configurable “heartbeat” wakeup triggers routine tasks.

That’s all that’s happening at the system level. The behavior and vault structure emerge from usage. We don’t need MCPs, complex integrations, and expansive harness logic. Claude already knows how to navigate through Markdown links, and knows what to do!

Extension

The control plane is shoved entirely into the context!

Scheduled tasks are introduced by conventions. The heartbeat prompt routes to a CLAUDE.md which gives instructions. Those instructions route to a scheduled_tasks.md. Every line of that looks like:

do once a week, last done 8/9/2026, route/to/task.md

CC is smart enough to downselect and fan out subagents. Maybe task.md just says to check the price of Bitcoin and mention in my daily note if it’s above $100k. (Just kidding don’t care!). None of the scheduling logic ends up in my harness!

Security

Groundhog runs CC with --dangerously-skip-permissions. The agent is an unprivileged system user in a systemd jail. Everything is read-only except the vault and its own home. What the jail can’t bound is the network, the inbox should be treated (guarded) like a shell.

The Dream

AI is kind of a trap for a lot of computer-touching individuals. Lots of raw brainpower has been dumped into agent frameworks and harnesses. There’s a dopamine hit of seeing an agent start to improve itself. My goal has been largely to remain aware while resisting the mind virus. Most of these projects are dead ends - Commentators have noted the dynamics at play lead to vertical absorption of anything interesting. If your product is a thin wrapper around a Claude model, then there’s not much barrier to them just implementing it.

Fear of being left behind drives a lot of AI-adjacent development. Instead I would like to engage with hope: that this technology should allow us to achieve more in less time, to make better decisions, and to be more aware of the world and the things that we care about.

1. Different components (websites) are treated as flake inputs.
2. The nginx config refers to the packaged outputs.
3. The entire server only builds if all the components build.
4. Deployments are atomic and minimal; the exact system is copied up.

This idea becomes particularly powerful once you have multiple nodes and can write integration tests for your entire system then deploy across multiple machines with a single command.

But for my personal use case I started to notice some slight friction. Say I’m updating this website with a new post. I’m working in its repo. Once I’m done, I tab back to the server config repo, run a nix flake update to pull in and re-pin the website, then deploy. It makes logical sense but doesn’t feel as ergonomic as it could.

The system also breaks down with more granular deployments. Say I want to give an untrusted tenant the ability to update paradigmatic.systems without interfering with the other services running on the same server. It’s not an unusual use case, and deploy-rs is designed with it in mind. Now I’ve finally taken the time to migrate from node-based to profile-based deployment.

Attempting to Keep Using deploy-rs

The deploy-rs API is built for this, and it should be a simple change!

In the Server Repo

I removed paradigmatic-systems from the flake inputs and instead defined an unprivileged deploy user:

users.users.paradigmatic-deploy = {
  isSystemUser = true;
  group = "paradigmatic-deploy";
  createHome = true;
  home = "/var/lib/paradigmatic-deploy";
  shell = pkgs.bashInteractive;
  openssh.authorizedKeys.keys = [
    "ssh-ed25519 AAAA..."
  ];
};
users.groups.paradigmatic-deploy = { };

nix.settings.trusted-users = [ "paradigmatic-deploy" ];

# ensure the profile directory exists before the first deploy
systemd.tmpfiles.rules = [
  "d /nix/var/nix/profiles/per-user/paradigmatic-deploy 0755 paradigmatic-deploy paradigmatic-deploy -"
];

Yes, I’ve contradicted myself by making paradigmatic-deploy a trusted user. I’ll come back to that later. But for now let’s say “we don’t think they’re going to upload malware, they just need guardrails from the other services”.

Then I proxy the website to the actual user profile:

services.nginx = {
  enable = true;
  virtualHosts."paradigmatic.systems" = {
    root = "/nix/var/nix/profiles/per-user/paradigmatic-deploy/website";
  };
};

In NixOS, a profile is a stable and mutable pointer into the (immutable) Nix store. It’s a symlink managed as a series of numbered generations. For a desktop environment it might wrap your entire system closure, including your kernel, services, and every installed package. In this case it’s just a single website!

In the Website Repo

We add deploy-rs to the website flake inputs, and configure it to set the website profile:

deploy.nodes.paradigmatic-systems = {
  hostname = "my-node";
  profiles.website = {
    sshUser = "paradigmatic-deploy";
    user = "paradigmatic-deploy";
    path = deploy-rs.lib.x86_64-linux.activate.profile
      self.packages.x86_64-linux.website;
  };
};

profiles.website is the rendezvous point for the two flakes. The path attribute is what actually gets copied up. The activate.profile wrapper is an activation hook that deploy-rs uses to verify the deployment. It’s also the villain of this story…

The Snag

The above code worked beautifully from my NixOS machine. I was excited to demonstrate the system to my “untrusted tenant” and went to run the deployment from her macOS machine. My eyes darted across deploy-rs.lib.x86_64-linux.activate.profile and briefly questioned things before seeing a blaring System Mismatch error.

The activation wrapper and the host system require different architectures. To build it correctly I’d need to pull in an entire Linux toolchain. Cross-compilation is pretty robust, but how much do I want to beef up my flake for a static website that won’t differ from one architecture to the next!?

An Easy Escape Hatch

One quick option offered by deploy-rs is the remoteBuild = true flag which pushes the derivation up and has the server build it on that end. Yes, it’s that simple. However, my cheap-o server is sized for the services it runs; not for pulling in the whole build-time closure.

Switching it Out to nix-copy

In the interest of moving forward with my life I opted to go under the hood to the same core Nix tools used by deploy-rs. The server flake remained basically the same! In the website flake I defined a simple deploy app:

  deploy-website = pkgs.writeShellApplication {
    name = "deploy-website";
    text = ''
      target="''${DEPLOY_TARGET:-paradigmatic-deploy@my-node}"
      site="${self.packages.${system}.website}"

      nix copy --no-check-sigs --to "ssh://$target" "$site"

      echo "==> Activating"
      ssh "$target" nix-env --profile /nix/var/nix/profiles/per-user/paradigmatic-deploy/website --set "$site"

      echo "==> Deployed https://paradigmatic.systems"
    '';
  };

All we’re doing is copying up the package and making the profile switch. The --no-check-sigs flag is the counterpart of being in the trusted-users list. Let’s talk about that briefly.

The Threat Model

I’ve given a fairly powerful capability to what I called an “untrusted” user, so I should probably address that a bit. Realistically, anyone who can write to the shared /nix/store is within my trust boundary.

Signing keys improve the situation with respect to accidents and shallow compromises. The trust is revocable and auditable, and composes into real CI architecture. But the tenant can still inject arbitrary store paths.

For handling a true scumbag tenant the design changes shape completely. They never get store write access whatsoever. They push up source and the server builds on its own terms. That, or they get a dedicated container or VM with its own store.

Conclusion

I needed more granularity in my deployment, so I broke out a piece of my server config. Instead of being baked in, it’s configured with a symlink that’s switchable by a specific user.

To route around a mild inconvenience I dropped deploy-rs in favor of Nix primitives. I’m using the same underlying manipulation of the nix store, so I still get atomicity, history, and garbage collection.

The main thing I lost is the “magic rollback” feature of deploy-rs where the system auto-reverts if SSH becomes unreachable. However, for this class of deployment (a static site swap) it’s not a big risk.

deploy-rs is a powerful tool for multi-node or multi-profile orchestration with interactive confirmation, and it’s on my roadmap to work on some more interesting examples later!

1: Deploy Over Network with deploy-rs

Based on my experience with a DigitalOcean VPS I knew I wanted to use the deploy-rs model on a local node. Here’s the basic idea:

• The node configuration lives in version control.
• You edit it and build it on your workstation.
• You push the complete build over the network onto the node.
• Errors are caught with atomic rollbacks.

That means I don’t need physical access to the machine. It can live in the basement with the router. I don’t even need to SSH in. Just edit the config and deploy. The process is very similar to the instructions in my other post:

1. Install NixOS on the node
2. Modify the configuration:
   • Add your workstation SSH key to users.root.openssh.authorizedKeys.keys
   • Enable Flakes
3. Copy the contents of /etc/nixos/ to your workstation and wrap them in a flake that specifies its hostname.
4. Add the deploy-rs configuration and then deploy.
5. Your node is unchanged, but now the configuration lives on your workstation and in version control.

Just make sure your SSH keys are loaded with ssh-add - it’s basic but this tripped me up as I thought it was a user configuration issue.

2: Define a DNS Overlay Server with dnsmasq

If you’ve served custom domains over LAN before, you may have gone into your router settings and added custom DNS entries. This is something I wanted to avoid: I wanted to be able to add new domains purely in my node configuration.

So the first step was to go to a different place in the router settings. This will be different for everyone. For me, it was under Broadband Connection settings -> “Obtain IPv4 DNS Addresses Automatically”. I adjusted this to point to the node’s IP.

Next, configuring the node to act as a DNS server was easy as pie with the dnsmasq module:

services.dnsmasq = {
  enable = true;
  settings = {
    server = [
      "8.8.8.8"
      "8.8.4.4"
    ];
    domain = "home";
    local = "/home/";

    address = [
      "/test.home/mynode"
    ];
  };
};

I tried using a cute custom domain extension but couldn’t get that to work. No big deal and I don’t care enough to pull that thread: .home and .lan both worked.

Now since that domain is resolving to the same node, we need to add a virtual host. The endgame is to reverse proxy these domains to various services, but we’ll start with a static response:

services.nginx = {
  enable = true;

  virtualHosts."test.home" = {
    locations."/" = {
      return = "200 'hello'";
      extraConfig = ''
        add_header Content-Type text/plain;
      '';
    };
  };
}

If everything worked, you should be able to hit http://test.home from any device on your network, and get a nice little hello!

3: Configure Frigate (Net Video Recorder)

If you’ve followed to this point, then your system is a blank slate for adding new services under custom domains. I’ll walk through this Frigate example since that’s the main thing I was migrating! It was straightforward configuring the rtsp feed of my IP cameras. But with naive settings the CPU usage was very high. It took some fiddling to get the Intel hardware acceleration enabled and reduce some of the overhead. I’ll annotate this fragment:

services.frigate = {
  enable = true;
  hostname = "localhost";

  settings = {
    mqtt.enabled = false;

    #This enables the Intel hardware acceleration
    ffmpeg = {
      hwaccel_args = "preset-vaapi";
    };

    cameras."front_camera" = {
      ffmpeg.inputs = [{
        path = "rtsp://admin:pwd@192.168.1.54:554/h264Preview_01_main";
        roles = [ "record" ];
      }
      # This second input needs to be specified even though we're not
      # doing detection, otherwise a high def feed is getting fed 
      # through to the dashboard! 
      {
        path = "rtsp://admin:pwd@192.168.1.54:554/h264Preview_01_sub";
        roles = [ "detect" ];
      }
      ];
      detect.enabled = false;
    };

    record = {
      enabled = true;
      retain = {
        days = 1;
        mode = "all";
      };
    };
  };
};

This keeps a trailing 24 hours of recording.

Intel Hardware Acceleration

This took a lot of trial and error, but got CPU usage down significantly (like, 75% to 2%)! Without knowing much about it, I will present without commentary.

systemd.services.frigate = {
  environment.LIBVA_DRIVER_NAME = "iHD";
  serviceConfig = {
    SupplementaryGroups = [ "render" "video" ];
    DeviceAllow = [ "/dev/dri/renderD128" ];
    AmbientCapabilities = "CAP_PERFMON";
  };
};
  

And in the hardware-configuration.nix:

hardware.opengl = {
  enable = true;
  extraPackages = with pkgs; [
    intel-media-driver
    intel-vaapi-driver
  ];
};

Reverse Proxy to Frigate Default Port

Last but not least, we need to add the address in dnsmasq.settings.address, and the reverse proxy config:

virtualHosts."frigate.home" = {
  locations."/" = {
    proxyPass = "http://127.0.0.1:5000";
    proxyWebsockets = true; 
  };
};

The websocket part is important as Frigate uses them for live views.

That’s it! Works like a charm.

Recap

We’re in a pretty good spot. We’ve got:

• Access to the entire corpus of nixpkgs with modules for many incredible open-source tools.
• Version-controlled configuration.
• Network deployments with atomic rollback.

That means we can host new services (like Jellyfin, Immich, NextCloud, Home Assistant, etc) with a few steps:

1. Enable it: services.jellyfin.enable = true;
2. Reverse proxy with nginx.
3. Add a DNS entry with dnsmasq.
4. deploy.

You have basically zero risk of bricking the machine with a failed experiment, or interfering at all with your existing services. If something goes awry you simply roll back the node and revert the config changes.

Next Steps?

I reserve the right to work (or not) in any of these directions:

• Being an affirmed Elixir enjoyer, I’m tempted to make a LiveView dashboard. That would make it really easy to wrap Frigate and augment with whatever custom live logic I want.

• I’ve been wanting an excuse to try out Slack’s Nebula. The idea there would be to make a network overlay connecting my VPS to the local node. Then I could (very carefully) access my services from public internet.

• Once we’ve got that, why not introduce some BEAM clustering so our LiveView backend is distributed? I have as many reasons to do that as I have not to! (It’s zero.)

The integration test framework lets you define virtualized nodes with pass/fail conditions on the behavior of the components therein. Furthermore the nodes can be embedded within an arbitrary network topology to test the overall system-of-systems behavior. With the tests defined, they’re wrapped into the very notion of validity for your configuration(s).

This system is obviously the future of infrastructure. NixOS is doing things that are deep on the long-term roadmap for other system-of-system solutions. You could burn serious man-hours approximating this capability in docker-compose and end up nowhere near the raw reproducible bare-metal power.

However, in my own experiments, the virtualization layer quickly made my $300 dev laptop smoke at the ears for anything beyond 1 node. That’s why I’m excited that Nixcademy has announced a new feature. An unnamed corporate patron has supported development of namespace-based containerization backed by systemd-nspawn.

Here’s an abbreviated example illustrating how I could bake this very post into my VPS deployment!

{
  description = "NixOS configuration with test";
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  };
  outputs = { self, nixpkgs }: 
  {
    checks.x86_64-linux.test = let
      pkgs = nixpkgs.legacyPackages.x86_64-linux;
    in pkgs.testers.runNixOSTest {
      
      name = "configuration-test";
      
      nodes.server = { config, pkgs, paradigmatic, ... }: {
        services.nginx = {
          enable = true;
          virtualHosts."_" = {
            root = "${paradigmatic.packages.${system}.website}";
          }
        };
      };
      
      nodes.client = { config, pkgs, ... } : {};

      testScript = ''
        server.start()
        client.start()
        server.wait_for_unit("nginx.service")
        client.wait_for_unit("multi-user.target")
        client.succeed("curl http://server/posts/integration-containers 
        | grep 'Hello from this very text block!'")
      '';
    };
  };
}

Nice!

Want to chat about NixOS adoption? Email me

The Tool and the Language

Let’s bootstrap ourselves with some circular facts.

Nix is a tool for building (or “packaging”) software components using instructions expressed in the Nix language. The Nix language is even able to package the Nix tool (which is mostly written in C++), thus closing the epistemological loop.

The language features first-class treatment of filesystem paths and URLs (to source code and tarballs, for example). Nix expressions are evaluated in a hermetic environment with no path variables and no files. All outside references get copied into content-addressed folders in the store, and marked as build-time dependencies in any derivation that gets defined. Retained runtime dependencies are calculated by scanning the actual binary for store paths.

The Build

The component is the result of realizing the derivation. That means grabbing all the store path contents and combining them in the prescribed way. Imagine you have 3 components that are build-time dependencies:

1. A compiler
2. Source code
3. A bash script that uses the compiler to build the source

The derivation describes where to find these, and the (obvious) way that they fit together. The result is content-addressed with a hash based on all its dependencies, and placed in the store.

nixpkgs

It turns out this scheme is highly flexible and repeatable. nixpkgs is a repo full of Nix expressions for over 120,000 packages. You can pull any one of them into an ephemeral shell to try it out, or install it system-wide if you’re using:

NixOS

Finally, notice that “software components” could have a very broad definition. So broad, in fact, to include an entire OS with all of the installed programs and services. That’s what NixOS is: A Linux distro defined entirely in Nix and built around the /nix/store path model instead of the more usual FHS. I’ve written a bit about how the Nix module system helps encapsulate complex system recipes into simple one-liners.

All my homies use NixOS. To paraphrase from NixOS is the endgame of distrohopping :

No more configuration drift - solved ✅

“Works on my machine!” - solved ✅

Dependency Hell - solved ✅

Virtual and development environments - solved ✅

package management - solved ✅

Ready to go deeper?

To get started I highly recommend working through the tutorials at nix.dev!

• social problems caused by scaling organizations to thousands of engineers
• existing complexity
• laziness or desire to throw money at a problem rather than solve it

While they do solve real technical problems, I’ll argue here that there’s superior tooling for most use cases outside of big tech and legacy systems.

Containerize or Modularize?

We need deployment consistency and environment isolation, and containers solve those!

The 2016 essay Docker Considered Harmful explains how Linux primitives solve the same problems in a more robust way. One valid criticism of this is that Docker can get a junior developer productive more quickly without needing to learn about arcane system settings.

Fine, so we need an abstraction to work with.

Does the abstraction need to expose us to a bloated ecosystem prone to drift? What if it could evaluate to the precise, minimal, and correct system without introducing overhead? What if it’s a better Docker image builder than Docker’s image builder?

Enter Nix with its module system. Nix approaches the “dependency hell” problem from first principles. It requires a radically different mental model, which is itself a social organization problem. This model, by the way, is laid out best in Eelco Dolstra’s 2006 PHD Thesis (PDF).

When you think about

• polyglot system with multiple language ecosystems working together
• co-existing packages with conflicting dependencies (i.e dfferent versions of python)

do you get a headache thinking about all the setup? Well then you should probably swallow some Nix pills. No other tool can encapsulate cross-ecosystem practices and Linux expertise so cleanly. A simple configuration change like

services.postgres.enable = true;

is the tip of a carefully crafted reproducible iceberg. This line of code hides a host of system-level changes including

• User and groups setup with correct isolation and permissions
• Directory structure with ownership and permissions
• Initialization, default template databases
• SystemD service with correct dependencies, start order, lifecycle and recovery and much more!

It’s a massive setup process that would normally be done manually, maybe captured in brittle shell scripts, or containerized. But here it’s a one-liner, and it’s exposed for use as a declarative model that allows completely deterministic and atomic system upgrades!

So while containers provide language-agnostic deployment, Nix achieves the same universality at the package level while maintaining better reproducibility and lower overhead. You can even spit out a Docker image as an afterthought if that’s what you really need.

Cluster or Cluster*@!#?

We need service discovery, load balancing, and observability! Kubernetes provides these with a vast ecosystem of battle-tested tools, and its nice declarative operator pattern for nearly every infrastructure need.

The infrastructure problem is solved by creating different problems: cognitive overhead, ecosystem lock-in, long development cycles, and significant cost markup. There are compelling reasons to look for a better alternative.

Well, the largest package repo in the world (Nixpkgs) has nice modules defined for over 20,000 world-class open-source tools. With a 3-line change to your system configuration, you’re now building a robust set of tools:

services = {
  nginx.enable = true;      #Load balancing
  consul.enable = true;     #Service discovery
  prometheus.enable = true; #Observability
  #You'll want to configure these, of course.

But that’s not it. The Nix flake output schema specifies nixosConfigurations as a key. Note the plural. So you might do something like:

nixosConfigurations = {
  web = mkNode "web" {
    services.nginx.enable = true;
    services.nginx.virtualHosts."web" = {
      locations."/api/" = {
      proxyPass = "http://${cluster.db.ip}:5000/";
    };
    app.db_address = cluster.db.ip
  };

  db = mkNode "db" {
    services.postgresql.enable = true;
    services.postgresql.enableTCPIP = true;
    services.postgresql.authentication = ''
      host all all ${cluster.web.ip}/32 trust
      '';
    api.enable = true
  };
};

where the 2 nodes configurations make them aware of each other.

The same flake can even include

• integration tests using the insanely powerful integration test driver
• deployment metadata with deploy-rs to deploy the whole cluster with 1 command

So the question then becomes, do you have a nest of messy legacy code and need to throw money at scaling it up? Or do you have the luxury of using the tools directly and scaling piecewise as needs arise?

Summary

It’s never going to be easy to retrofit legacy enterprise systems. But for designing new systems, the NixOS advantage is massive. Your entire system configuration, from kernel to application dependencies to infrastructure services, is a single, reproducible, version-controlled artifact. It allows for

• One deployment mechanism
• Deterministic deployments
• Exact parity between development and production

and most importantly, a level of autonomy and sovereignty that you yield when your system is built on unstable abstractions.

1. SSH in and edit the configuration files (or copy them over) and then run nixos-rebuild switch which triggers the node to pull and build all the necessary items.

2. Check and build the configuration locally, and copy the entire closure across.

At a glance there might not be an advantage to one or the other. But consider if you’re deploying custom content that isn’t part of nixOS builtin configuration. To use method (1) you would need to clone all your repos on the server to be able to rebuild. Then every update requires you to ssh in and pull.

That’s why (2) is the much better option. We will use deploy-rs to implement it on DigitalOcean.

1) Enable flakes on the server

If you followed the previous instructions you’ve got a local folder full of configuration pulled from your node. Go ahead and turn that into a git repo before getting too far into this.

Adjust your configuration.nix

{ pkgs, ... }: {
  imports = [
    ./hardware-configuration.nix
    ./networking.nix
  ];

  environment.systemPackages = with pkgs; [ vim ];

  boot.tmp.cleanOnBoot = true;
  zramSwap.enable = true;
  networking.hostName = "your-hostname";
  networking.domain = "";
  services.openssh.enable = true;
  users.users.root.openssh.authorizedKeys.keys = [''your key here'' ];
  system.stateVersion = "25.05";

  nix.settings.experimental-features = [ "nix-command" "flakes" ];
}

The main changes are to add the content of host.nix (personal preference but you can go ahead and delete that), and enable the flakes feature. Push the whole configuration folder back up and do a rebuild:

rsync -av --delete --exclude='.git' ./ [node-name]:/etc/nixos/
ssh [node-name] "sudo nixos-rebuild switch --flake /etc/nixos#default"

2) Wrap the original configuration in a flake

Now, working locally again, create a new flake.nix:

{
  description = "NixOS configuration";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-25.05";
    deploy-rs = {
      url = "github:serokell/deploy-rs";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  outputs = { self, nixpkgs, deploy-rs }: let
    system = "x86_64-linux";
  in {
    nixosConfigurations.default = nixpkgs.lib.nixosSystem {
      inherit system;
      modules = [
        ./configuration.nix
      ];
    };

    deploy.nodes.default = {
      hostname = "[node-name]";
      profiles.system = {
        sshUser = "root";
        path = deploy-rs.lib.${system}.activate.nixos self.nixosConfigurations.default;
        user = "root";
      };
    };
    checks = builtins.mapAttrs (system: deployLib: deployLib.deployChecks self.deploy) deploy-rs.lib;
  };
}

This flake:

1. wraps the original system, importing it to nixosConfigurations.default.
2. describes the deployment target in deploy.nodes.default.

3) Deploy it

You can run deploy-rs straight from github:

nix run github:serokell/deploy-rs .#default

or hit a nix profile install github:serokell/deploy-rs so that you can just use the deploy command.

This should succeed and leave your server right where you started (since the actual configuration is unchanged), but now you have a nice flake to work with locally.

1) Set up a new droplet

• Choose Ubuntu 22.04
• Add SSH keys for something you have a local IdentityFile for.
• Under “Advanced Options” -> “Add initialization scripts” paste

#cloud-config
write_files:
- path: /etc/nixos/host.nix
  permissions: '0644'
  content: |
    {pkgs, ...}:
    {
      environment.systemPackages = with pkgs; [ vim ];
    }
runcmd:
  - curl https://raw.githubusercontent.com/elitak/nixos-infect/master/nixos-infect | PROVIDER=digitalocean NIXOS_IMPORT=./host.nix NIX_CHANNEL=nixos-25.05 bash 2>&1 | tee /tmp/infect.log

2) SSH in and copy config down

Add the node’s SSH config to ~/.ssh/config

Host [node-name]
        HostName [IP-address]
        User root
        IdentityFile ~/.ssh/[identity]

Now you should be able to ssh [node-name] and cat /etc/nixos/configuration.nix to see your new system.

Start a new directory for containing the node’s configuration locally. Maybe call it [node-name]-deployment.

On the server, run scp [node-name]:/etc/nixos/* ..

Now you’ve got the remote configuration in hand. If you wanted to alter the node, the naive way to do it is edit the configuration, push it back over, and run sudo nixos-rebuild switch. But there’s a better way to approach this that involves building the system locally. We’ll continue in setting up deploy-rs.