Is Quick Start | Panix not good?
Thanks for taking interest.
-
The approach was chosen, to keep it universally compatible with nix native tooling.
-
To keep project sane development and maintainability wise, a constraint is that we only have 1 source of truth. Either separate config (yaml, nix) or directly in nixosConfigurations. Making it in nixosConfigurations is just more problematic, for all the features we have currently, and may have in the future.
-
I have opened a discussion for this already feat: draft: Support deploying multiple profiles per machine (home-manager, nixvim, system-manager, etc.) · Issue #5 · mihakrumpestar/panix · GitHub. While I would be interested in implementing it, it is not trivial, as the profiles are not exactly standard. Please provide any insight that may make this easier to logically implement.
-
hostnamedoes not need to be hardcoded in configuration. It can be resolved from DHCP systemd: Allow setting the transient hostname via DHCP by primeos · Pull Request #91232 · NixOS/nixpkgs · GitHub.As for the use case: lets say you are a system admin on a company, you need to deploy to 50 identical machines, so you are not going to write 50 nixosConfiguration entries because of that. With Panix nixosConfiguration deduplication, you can deploy all of them with the same nixosConfiguration, while they have their hostname and IP set by DHCP server. This means every time you only have 1 rebuild, instead of 50. But yes, this is not something that is regularly practiced, probably because there has not existed a tool that could do this. You can also bootstrap all 50 machines at once with the single nixosConfiguration too. This is the value Panix provides.
As always, I am fully open to suggestions and improvements, especially on issue #5. If something could be done better, it should be.
2 Likes
Here is an update after a bit less than three months. The tool has changed a lot since, six releases (v0.7.1 → v0.9.2).
Main change: Panix is no longer a NixOS deployment tool. It is now a Universal Nix Deployment Orchestrator: it deploys any flake installable, not just NixOS systems. Each output type carries its own build and activation semantics, while packages installs directly into the target’s profile with nix profile add.
Built-in output types now include:
nixosConfigurations(NixOS, deploy and bootstrap)homeConfigurations(home-manager)darwinConfigurations(nix-darwin)nixOnDroidConfigurations(nix-on-droid)systemConfigs(system-manager)packages(plain packages into the user profile, e.g. nixvim or nvf)maidConfigurations(nix-maid bundles)
and multiple types can target the same machine in a single run:
fleet:
flakes:
my-infra:
installables:
nixosConfigurations:
workstation:
machines:
workstation:
homeConfigurations:
dev:
machines:
workstation: # same machine, different installable type
There is also support for custom output types: If your flake exposes outputs under a non-standard attribute, you can declare custom types under output_types with their own build and activation semantics. Docs: Custom Output Types | Panix
If you think a type should be built-in, open an issue. The goal is comprehensive coverage of the Nix ecosystem.
Added also opt-in auto_rollback, settable at fleet, flake, installable or machine level. Panix captures each machine’s pre-deploy generation during Inspect, and when activation fails it reverts to that generation. Docs: Auto Rollback | Panix
Everything else:
- e2e tests that install and redeploy real VMs across installable types (NixOS, home-manager, system-manager, packages, nix-maid), including an auto-rollback scenario
- TUI engine optimizations, lower CPU and memory usage
- shell completions that activate automatically in Nix environments
- optional Cachix cache with prebuilt binaries
- Lix compatibility fixes
- smaller binary
New demo:
TUI:
2 Likes