Clan Core Changelog 02.02.2026

Development Deployments
1

Clan is a toolkit that makes it easier to manage networks of VPN-connected NixOS machines.
The ultimate goal is to lower the barrier to self-hosted services massively and allow anyone to achieve this without special hardware. As of now, using Clan still requires NixOS knowledge, but it already combines several of our Open-Source projects that you may know (nixos-anywhere, sops-nix, nixos-generators, disko, …) into a uniform CLI.

:memo: Changelog

:brain: Data Mesher

  • V2 progress:
    • Set mtime to match the signature signed_at #292.
    • Set output files to be read-only #293.
    • Allow subdirectories in file paths; add systemd hardening for the NixOS service #295.
    • NixOS module refinements #296, #297, #298.
    • Transport encryption #299.
    • First version of the V2 Clan Service module in clan-core #6478.
    • Fixed NSS integration for DNS.
  • NSS V2:

:toolbox: CLI, CI & Services

  • CLI improvements:
    • pkgs/cli: Init init subcommand #6561.
    • pkgs/cli: Remove clan flakes inspect #6545.
    • pkgs/clan/create: Automatically fill in clan templates #6635.
    • Allow creation in an already existing git repo #6564.
    • Symlink caching for nix shell paths #6549.
  • CI & tests:
    • Fixed our update test #659 (result: patch for Nix in containers).
    • Established very comprehensive linting rules #6556.
  • Services:
    • TODO: Sidebus integration #1.

:books: Docs & Website

  • Implemented the holistic site with docs versioning #6617.
  • Made the site build with existing markdowns; fixed URLs #6585.
  • Site CLI and tooling:
    • Introduced a simple site CLI similar to clan-app (clan-site, clan-site -b, clan-site build, clan-site build -b) #6624.
    • README instructions and VSCode linting settings #6624.
  • Guides & migration:
    • Replacement and migration guide for the admin ClanService #6608.

:optical_disk: Imaging & Installer

:locked_with_key: Installation & Secrets

  • Add generateRootKey option to the sshd module #6609.

:broom: Maintenance & Tech Debt

  • Remove unused vm-store #6636.

:desktop_computer: VMTech / Desktop Integration

  • wl-cross-domain-proxy:
    • Fix copy & paste / drag & drop #20.
    • Switched to wl-cross-domain-proxy in munix.
  • VM/munix:
    • Using static userborn in the Nix VM template.
    • Pass through the port publish arg in munix #11.
    • TODO: muvm bug requiring an outgoing packet first #178.
4 Likes
2

Something I’ve been wondering: is it possible to use clan to define “worker” machines?

Say I want to scale up and down a collection of worker nodes in something like a build farm. Having skimmed the docs it seems like clan is oriented towards a fixed collection of machines with individually assigned, persistent names. The build farm scenario may have a few machines like this (coordinators), but a large collection of identical, ephemeral machines with no meaningful names other than “worker1”, “worker2”, etc.

3

Hey @zmitchell,

this is possible by using clan as a python library and then writing your own code to generate / install and delete machines. I combine that with terraform for whole setup automation. There is a little blog post about it here: VPN Benchmarks Part 1 | Clan .

Example code: vpn-bench/pkgs/vpn-bench/vpn_bench/install.py at 74bfa56b80922c1dc9d12bedf70b5c2522663db8 · Qubasa/vpn-bench · GitHub

however do note that clan_lib is not API stable, so the api will change frequently.

1 Like
4

Really cool, thanks!