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 flake amont compile ZeroClaw à partir des sources. Avec les fonctionnalités expérimentales nix-command et flakes de Nix activées, vérifiez la CLI sans installer de service système :
nix run github:zeroclaw-labs/zeroclaw -- --version
nix run github:zeroclaw-labs/zeroclaw -- --help
Le paquet par défaut est la CLI ZeroClaw ; la chaîne d’outils de développement est exposée séparément via nix develop. La construction du paquet peut prendre du temps lorsque le cache est froid. Pour inspecter une copie locale du dépôt :
nix build .#zeroclaw
./result/bin/zeroclaw --version
nix flake check
Exécuter la CLI avec nix run ne l’ajoute pas au PATH de votre shell de connexion. Pour une installation NixOS persistante, Nixpkgs fournit pkgs.zeroclaw :
nix
environment.systemPackages = [ pkgs.zeroclaw ];
La version du paquet Nixpkgs suit votre épinglage de Nixpkgs ; le flake en amont suit la révision de ZeroClaw sélectionnée. Ces deux versions peuvent différer. Le module ci-dessous utilise pkgs.zeroclaw par défaut et démarre sa commande zeroclaw daemon. Définissez services.zeroclaw.instances.<name>.package pour utiliser un autre paquet, par exemple inputs.zeroclaw.packages.${pkgs.stdenv.hostPlatform.system}.zeroclaw lorsque le flake de votre système possède une entrée zeroclaw pointant vers ce dépôt.
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";
Suivant
- Gestion des services : l’unité systemd que ZeroClaw génère sur les hôtes non-Nix
- Providers → Configuration : le schéma de configuration
settingsreflète