NixOS

ZeroClaw incluye un módulo NixOS multi-instancia en nix/module.nix. Ejecuta uno o más agentes bajo systemd con valores predeterminados de endurecimiento apropiados para un proceso expuesto a internet, siguiendo el modelo de services.restic.backups.

El paquete

El flake upstream compila ZeroClaw desde el código fuente. Con las funciones experimentales nix-command y flakes de Nix habilitadas, verifica la CLI sin instalar un servicio del sistema:

nix run github:zeroclaw-labs/zeroclaw -- --version
nix run github:zeroclaw-labs/zeroclaw -- --help

El paquete predeterminado es la CLI de ZeroClaw; la cadena de herramientas de desarrollo se expone por separado a través de nix develop. Compilar el paquete puede tardar bastante con una caché vacía. Para inspeccionar una copia local del repositorio:

nix build .#zeroclaw
./result/bin/zeroclaw --version
nix flake check

Ejecutar la CLI con nix run no la añade al PATH de tu shell de inicio de sesión. Para una instalación persistente en NixOS, Nixpkgs proporciona pkgs.zeroclaw:

nix

environment.systemPackages = [ pkgs.zeroclaw ];

La versión del paquete de Nixpkgs sigue la fijación (pin) de Nixpkgs que uses; el flake upstream sigue la revisión de ZeroClaw seleccionada. Estas pueden diferir. El módulo siguiente usa pkgs.zeroclaw por defecto e inicia su comando zeroclaw daemon. Establece services.zeroclaw.instances.<name>.package para usar otro paquete, por ejemplo inputs.zeroclaw.packages.${pkgs.stdenv.hostPlatform.system}.zeroclaw cuando tu flake del sistema tenga una entrada zeroclaw que apunte a este repositorio.

Instancia única

La pertenencia a services.zeroclaw.instances.<name> es la señal de activación; no existe un enable de nivel superior. Cada instancia obtiene su propia unidad de systemd, directorio de estado y usuario del sistema.

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 de systemd, sustituido desde environmentFile al iniciar
        allowed_users = [ "12345" ];
      };
    };
  };
}

settings refleja ~/.zeroclaw/config.toml como un attrset de Nix, renderizado en ${dataDir}/config.toml (modo 0600). Los secretos viajan a través de environmentFile, nunca de settings: el ExecStartPre de la unidad ejecuta envsubst para que las referencias $VAR se resuelvan al inicio, manteniendo la copia de /nix/store libre de texto plano. El esquema de configuración (encabezados de sección, convención de tipos/alias) es idéntico al de todas las demás plataformas.

Múltiples instancias

El módulo tiene forma de attrsOf submodule, por lo que N tenants en un host se leen igual que uno. Las instancias pueden compartir un usuario cuando exactamente una lo crea y el resto establece createUser = false.

nix

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

Opciones

La superficie completa de opciones (package, user, group, createUser, dataDir, settings, environmentFile, extraConfig, bindReadOnlyPaths) y el patrón de secretos están documentados en nix/README.md. Para sobrescribir un campo de serviceConfig, use el mecanismo de escape estándar de NixOS en lugar de una opción del módulo:

nix

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

Gestión de servicios: la unidad de systemd que ZeroClaw genera en hosts que no son Nix
Proveedores → Configuración: el esquema de configuración settings refleja

ZeroClaw Docs