NixOS

ZeroClaw fournit un module NixOS multi-instance dans nix/module.nix. Il exécute un ou plusieurs agents sous systemd avec des paramètres de durcissement par défaut adaptés à un processus exposé à Internet, sur le modèle de services.restic.backups.

Le paquet

Le module invoque ${pkgs.zeroclaw}/bin/zeroclaw daemon. pkgs.zeroclaw n’est pas encore dans nixpkgs ; son suivi est assuré dans #5987. En attendant son intégration, compilez le binaire vous-même et indiquez-le au module via l’option package :

nix

services.zeroclaw.instances.me.package =
  pkgs.callPackage ./zeroclaw.nix { };

Pour la même raison, nix run github:zeroclaw-labs/zeroclaw ne lance pas l’agent. nix run résout apps.<system>.default puis packages.<system>.default ; ce flake ne définit aucun apps, et son packages.default est la chaîne d’outils Rust (pour le shell de développement), donc la commande exécuterait la dérivation de la chaîne d’outils, pas ZeroClaw. Sur toute autre plateforme, install.sh est la méthode prise en charge.

Instance unique

L’appartenance à services.zeroclaw.instances.<name> constitue le signal d’activation ; il n’existe pas d’option enable de premier niveau. Chaque instance dispose de sa propre unité systemd, de son propre répertoire d’état et de son propre utilisateur système.

nix

{ config, pkgs, ... }: {
  imports = [ ./path/to/zeroclaw/nix/module.nix ];

  age.secrets.zeroclaw-bot-token.file = ./secrets/zeroclaw-bot-token.age;

  services.zeroclaw.instances.me = {
    environmentFile = config.age.secrets.zeroclaw-bot-token.path;
    settings = {
      providers.models.anthropic.home.model = "claude-sonnet-4-6";
      agents.assistant = {
        model_provider = "anthropic.home";
        risk_profile = "assistant";
        channels = [ "telegram.home" ];
      };
      risk_profiles.assistant = { };
      channels.telegram.home = {
        enabled = true;
        bot_token = "$BOT_TOKEN";   # $VAR systemd, substitué depuis environmentFile au démarrage
        allowed_users = [ "12345" ];
      };
    };
  };
}

settings reflète ~/.zeroclaw/config.toml sous forme d’attrset Nix, rendu vers ${dataDir}/config.toml (mode 0600). Les secrets transitent par environmentFile, jamais par settings : le ExecStartPre de l’unité exécute envsubst afin que les références $VAR soient résolues au démarrage, ce qui garde la copie dans /nix/store exempte de texte en clair. Le schéma de configuration (en-têtes de section, convention type/alias) est identique à celui de toutes les autres plateformes.

Instances multiples

Le module est de la forme attrsOf submodule-, donc N tenants sur un même hôte se lisent comme un seul. Les instances peuvent partager un utilisateur lorsqu’exactement une seule le crée et que les autres définissent createUser = false.

nix

services.zeroclaw.instances = {
  alice = { environmentFile = "/run/secrets/alice/identity.env"; settings = { /* … */ }; };
  bob   = { environmentFile = "/run/secrets/bob/identity.env";   settings = { /* … */ }; };
};

Options

La surface complète des options (package, user, group, createUser, dataDir, settings, environmentFile, extraConfig, bindReadOnlyPaths) et le modèle de gestion des secrets sont documentés dans nix/README.md. Pour redéfinir un champ serviceConfig, utilisez le mécanisme de contournement standard de NixOS plutôt qu’une option de module :

nix

systemd.services."zeroclaw-me".serviceConfig.MemoryMax = "512M";

Gestion des services : l’unité systemd que ZeroClaw génère sur les hôtes non-Nix
Providers → Configuration : le schéma de configuration settings reflète

ZeroClaw Docs