You can use everything that nixos-generate generated for you. A typical pattern is:

{
  alpha = import ./hosts/alpha/configuration.nix;
}

I'm currently doing a hack like

    nixosConfigurations = lib.mapAttrs (name: config: let
      nodeNixpkgs = self.outputs.colmena.meta.nodeNixpkgs.${name} or self.outputs.colmena.meta.nixpkgs;
      nodeNixos = import (nodeNixpkgs.path + "/nixos/lib/eval-config.nix");
      in nodeNixos {
        modules = [
          self.outputs.colmena.defaults
          config
          inputs.colmena.nixosModules.deploymentOptions
          {
            _module.args.name = name;
            _module.args.nodes = self.outputs.nixosConfigurations;
            nixpkgs.overlays = [ nodeNixpkgs.lib.flakeOverlay (import ./overlay.nix) ];
          }
        ];
        inherit (nodeNixpkgs) system;
      }
    ) (builtins.removeAttrs self.outputs.colmena ["meta" "defaults"]);

to be able to get at least an approximation of the configs (enough to be able to build it in hydra, for example)

And the colmena package itself could be re-exported to my flake.
So that I do nix run .#colmena apply and it uses the colmena version pinned in my flake.

So you mean something like:

mkFlake ...

->

nixosConfigurations = ...
__colmena = ...

To further expand on that, consuming the existing nixosConfigurations is problematic, since Colmena needs to insert two things into the configuration: Modules (deployment.* options and configs) as well as module arguments (name and nodes which allows you to refer to configurations of other nodes in the cluster). This is in part following the design decisions of NixOps and morph. Inserting them cannot be cleanly done in case of nixosConfigurations which contains complete, evaluated configurations rather than individual NixOS modules.

We could remove this need and make the user specify the deployment.* configs externally, outside the NixOS configuration. This is the approach that deploy-rs takes (the deploy output). The downside is two-fold:

1. The level of configuration composition possible will be limited. As an example, I set deployment.tags = [ "routers" ]; in my router module so enabling it will automatically make colmena apply --on @routers deploy to this node. Additionally, I use the added nodes argument extensively in my configuration to set up a WireGuard mesh and iBGP peerings between my nodes.
2. The effect Colmena can have on the target node configuration will be limited. For instance, Colmena creates the ${name}-key.service for each secret file defined in deployment.keys, which will no longer be possible. deploy-rs uses a deploy binary copied alongside the profile to implement activation and other features.

The end result is a level of functionality noticeably different from "normal" Colmena that would necessitate a lot of documentation changes and still be confusing to users.

My interpretation is

hive = { defaults = ...; meta = ...; nodeA = ...; };
nixosConfigurations = (colmena.evalHive self.outputs.hive).nixosConfigurations;

In reply to @zhaofeng:zhaofeng.li

To further expand on that, consuming the existing nixosConfigurations is problematic, since Colmena needs to insert two things into the configuration: Modules (deployment.* options and configs) as well as module arguments (name and nodes which allows you to refer to configurations of other nodes in the cluster). This is in part following the design decisions of NixOps and morph. Inserting them cannot be cleanly done in case of nixosConfigurations which contains complete, evaluated configurations rather than individual NixOS modules.

We could remove this need and make the user specify the deployment.* configs externally, outside the NixOS configuration. This is the approach that deploy-rs takes (the deploy output). The downside is two-fold:

1. The level of configuration composition possible will be limited. As an example, I set deployment.tags = [ "routers" ]; in my router module so enabling it will automatically make colmena apply --on @routers deploy to this node. Additionally, I use the added nodes argument extensively in my configuration to set up a WireGuard mesh and iBGP peerings between my nodes.
2. The effect Colmena can have on the target node configuration will be limited. For instance, Colmena creates the ${name}-key.service for each secret file defined in deployment.keys, which will no longer be possible. deploy-rs uses a deploy binary copied alongside the profile to implement activation and other features.

The end result is a level of functionality noticeably different from "normal" Colmena that would necessitate a lot of documentation changes and still be confusing to users.