Colmena separates NixOS deployment from machine provisioning
Colmena targets existing machines with parallel deployment and no deployment database. Evaluation proceeds in memory-aware chunks, while cloud resource management remains outside its scope.
A tool that deploys an operating-system configuration does not necessarily need to create the machine receiving it. Colmena makes that boundary explicit in its February 13 announcement. It is a stateless deployment tool for existing NixOS hosts, with parallel deployment built into its design. It does not provision cloud resources or manage their complete lifecycle.
The boundary explains its relationship to NixOps. The author describes compatibility with configurations for the SSH-only none backend, with small modifications, and with morph configurations. This is a deliberately limited compatibility claim. Support for a NixOps deployment description does not mean Colmena implements every resource backend or state-management feature that NixOps offers.
I am interested in declarative infrastructure because desired state can be inspected as configuration. A deployment tool is useful when its responsibilities are equally clear. Colmena's distinction between configuring an existing host and owning its lifecycle gives the reader a concrete basis for deciding whether stateless operation fits the problem.
Stateless deployment leaves lifecycle elsewhere
The author identifies the NixOps state database as a collaboration difficulty when several people need to deploy. Morph removes that state but, in the announcement's account, lacks the parallelism needed for the author's larger host set. Colmena combines a stateless approach with parallel work, rather than treating those as alternative goals.
Stateless here describes the deployment tool. It does not mean the target machines lack state, or that every service on them becomes disposable. It also does not mean cloud resources can be created without identifiers or lifecycle information. Colmena avoids that second problem by limiting its scope to machines that already exist.
This is an architectural tradeoff. A separate process must arrange for the host and its access details to be available. Colmena can then focus on applying the system configuration. The announcement does not provide an account database or a replacement cloud resource inventory, and its author explicitly says that managing those lifecycles would inevitably introduce state.
For teams whose machines are already managed elsewhere, that separation can simplify collaboration. There is no Colmena deployment database to coordinate as an additional source of deployment authority. The desired configurations still need controlled distribution, and operators still need a policy for concurrent changes. Stateless operation removes one coordination object, not every possible disagreement about what a machine should run.
Parallel work starts with evaluation
An author reply on the announcement day explains how evaluation is scheduled. Colmena evaluates machines in chunks, choosing the chunk size based on available RAM. Evaluating all hosts together consumes too much memory in the author's case, while evaluating each one separately wastes CPU time and memory. The implementation takes a middle course by evaluating several together.
That detail matters because deployment time includes more than copying a completed system. Nix has to evaluate configuration before it can build the resulting system. Parallel transfer alone would leave an expensive serial evaluation phase unchanged. The reply identifies evaluation as a part of the process that receives its own resource policy.
It also avoids equating parallelism with starting every host at once. Memory limits can constrain useful concurrency before CPU capacity does. A chunking policy acknowledges that cost. The author's report concerns an existing installation of more than forty hosts, but it does not provide a universal throughput benchmark for arbitrary NixOS configurations.
The announcement's example output separately shows builds, store-path copying, and activation progress for named hosts. These stages help explain the tool's practical interface. An operator can see that one host has activated while another is still receiving its system. That is evidence of independent progress, not a promise that every machine changes state simultaneously.
Tags and package pins define deployment scope
Colmena supports selecting hosts by tag. The announcement demonstrates the following command, with the tag prefixed by @.
colmena apply --on @tag-a
The selection occurs before applying the configuration to the chosen machines. Tags therefore provide a way to define a subset without duplicating the configuration collection. The example uses a named group, but the source does not establish any automatic availability policy for services spanning those hosts. Selection and application-level rollout coordination remain different operations.
Per-node overrides of Nixpkgs pinning are another advertised capability. They let individual machines select a package collection independently of the common choice. This is useful for describing an exception in the configuration, though the announcement does not establish what a particular mixed-version fleet should contain. The tool expresses the choice without making it an operational recommendation.
The author also supplies colmena introspect to extract information from configurations. That fits a stateless tool whose configuration is an important source of information. The announcement names the command but does not document a complete query interface, so it is premature to infer one from later documentation.
Local activation supports workstation workflows
Colmena can deploy to the local machine as well as remote hosts. The author connects this to a preference for a nixos-rebuild style of managing desktops. The feature matters because a deployment collection can include a workstation without requiring a separate remote-only workflow for it.
The NixOS 20.09 upgrade manual describes the existing channel-based nixos-rebuild switch --upgrade workflow. Channels distribute expressions and associated binaries, and the rebuild applies the selected system. Colmena operates in that broader configuration model while adding a host collection and parallel deployment machinery. It does not replace NixOS's declarative system construction with imperative package installation commands.
I find local support a useful part of the scope because declarative management should not stop at a server boundary. The same clarity about responsibility still applies. A tool can activate a workstation configuration without also being responsible for creating that workstation or deciding its package policy.
The February announcement says no stable release exists yet. The author has been using the tool and is working through remaining problems. Today's available proposition is consequently an early deployment implementation with a defined boundary, memory-aware evaluation, and support for selected existing hosts. Its compatibility claims should be assessed within that boundary.