Deploy from an alternative host

By default, a single admin workstation deploys the entire fleet (see Deployment). A single deployer is a single point of failure: if it goes down, no just apply is possible anymore. You can promote an alternative host, typically a powerful and always-available server, into a standalone backup deployer capable of managing the fleet in place of the admin workstation.

The principle

A deployer relies on only four elements. Two already exist on each host, two are prepared once.

Element	Detail	To do
Tooling	colmena, just, sops (via an admin profile)	Enable a flag
Binary cache	harmonia specific to the deployer	Enable a service
Workspace	clone of the repository (config + framework)	Clone + sync
SSH identity nix	already authorized on all hosts	Copy the private key

The target topology : two deployers fed by a common source, each capable of deploying the fleet.

Enable the tooling

Deployment tools ship with an admin home profile (e.g. nix-admin), but remain hidden until the host declares itself an admin host. Enable this flag on the alternative host:

# usr/machines/<hôte>/features.nix
darkone.admin.nix.enable = true;

• The user who will deploy must have an admin home profile.
• On a headless server, the graphical packages of the profile are automatically excluded: the installed tooling stays lightweight.

Keep the server host profile

There is no need to switch the host to the admin-desktop profile, which would pull in an entire desktop. The darkone.admin.nix.enable flag alone is enough to unlock colmena and just in the user’s home.

git refuses to open the repository: safe.directory

darkone.admin.nix.enable installs the tooling, but colmena/nix evaluates the flake under the nix user, not the one who cloned /etc/nixos: git then refuses to open the repository (repository path ... is not owned by current user). Also enable:

# usr/machines/<hôte>/features.nix
darkone.console.git.enable = true;

This module declares /etc/nixos as a safe.directory in /etc/gitconfig, readable by any system user. A host already set to the admin-desktop or darkone.profile.advanced.enable profile already has it: nothing more to do.

Attach a binary cache

Recommended: give the deployer its own binary cache. It builds the fleet, then re-serves its derivations to other hosts.

etc/config.yaml

services:
  harmonia:
    global: true

• global: true makes the cache reachable cross-zone via VPN, useful when the deployer and its targets are not in the same zone.
• The signing key is already managed by sops, common to the whole network: nothing new to provision.

Roaming deployer

An alternative deployer on a laptop that changes zone? Also enable roaming mode for the cache (darkone.service.nix-cache.roaming): its substituters follow the zone it is connected to instead of staying fixed on its declared zone.

Set up

1. Declare and deploy. From the admin workstation, apply the two options above, regenerate, then deploy the alternative host:

   just generate
   just apply <hôte>

2. Clone the workspace on the alternative host, at the same path as on the admin workstation, with the framework sub-repository in the same location.

   Locked path

   The flake references the framework via an absolute path (git+file:///etc/nixos/dnf). The clone must live at that exact location, otherwise evaluation will fail.

3. Share the source. A common git remote, or regular pull from the admin workstation, keeps both deployers in sync. Only committed state is deployed.

4. Copy the private key of the deployment user (nix) to the alternative host, with 600 permissions and owned by nix:

   # on the alternative host
   /home/nix/.ssh/id_ed25519

   Its public key is already authorized across the entire fleet, so no redeployment of access rights is needed.

5. Validate from the alternative host:

   colmena --version
   just apply <cible-témoin> test

Two deployers, one golden rule

One deployer at a time

Each deployer pushes from its own clone. Two concurrent apply runs can apply two divergent states to the fleet. Always deploy from one workstation at a time and keep the clones synchronized via the shared remote.

How far does this deployer go

Usage	Admin sops key
Deploy and inspect (apply, exec, enter, reboot)	Not required
Edit or manage secrets	Required

Deployment alone does not need the admin key: secrets are decrypted on each target using its infra key. Only copy the admin key to the alternative host if you also want to manage secrets there.