Every SMB knows the feeling: you SSH into the web server and realize it’s slightly different from the app server, which is different from the CI runner. Packages installed by hand, a config tweaked “temporarily” two years ago, a cron job only one box has. You don’t have a snowflake problem — you have a whole fleet of snowflakes.
That’s exactly why NixOS keeps dominating conversations on r/devops and Hacker News in 2026. After a decade of Ansible plays and shell scripts, small teams are discovering what declarative, reproducible configuration actually feels like: one file describes your entire server, the build is bit-for-bit reproducible, and a bad change is undone with a single command. This guide shows you how to manage 5 to 50 VPS boxes as a single NixOS flake — no drift, no snowflakes, no scary Friday rollouts.
¿Por qué NixOS (y no solo otra herramienta de configuración)?
Tools like Ansible are imperative: you write a playbook of steps (“install this, copy that, restart the other”) and trust that the server ends up in the right state. That works, but the state is only as good as your discipline. Miss one server, edit one file by hand, and six months later you have drift — and drift is how production incidents start.
NixOS removes the drift structurally. The entire operating system — kernel, packages, services, firewall, even /etc files — is built from a declarative specification into an immutable /nix/store. Changes are atomic: nixos-rebuild switch builds the new system, activates it as a new generation, and if anything breaks, you roll back instantly. There is no “partial state”. Either the new system is active, or the old one is.
For an SMB that’s the difference between “we hope the playbook ran everywhere” and “every server is built from the same hash-pinned definition”. It’s the same philosophy we covered in Infrastructure from Code (IfC) — the system definition is the artifact, not a script that approximates it. NixOS 25.11 even ships the faster, Python-based nixos-rebuild-ng as default, so rebuilds are quicker than ever.
The honest caveat: Nix has a learning curve, and it’s only worth it for fleets you control end-to-end with Linux. If your estate is mostly Windows or throwaway containers, the ROI is smaller. Start with your 3-10 most important Linux boxes.
Un flake para gobernarlos a todos
Everything in NixOS 2026 starts from a flake — a git-tracked, lockable project that pins every input. A minimal fleet flake looks like this:
# flake.nix
{
description = "ACME Corp VPS fleet";
inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-25.05";
outputs = { self, nixpkgs }: {
nixosConfigurations.web1 = nixpkgs.lib.nixosSystem {
system = "x86_64-linux";
modules = [ ./hosts/web1.nix ];
};
nixosConfigurations.app1 = nixpkgs.lib.nixosSystem {
system = "x86_64-linux";
modules = [ ./hosts/app1.nix ];
};
};
}Each host file is a plain NixOS module. You stop thinking “server” and start thinking “role”:
# hosts/web1.nix
{ pkgs, ... }: {
imports = [ ./common.nix ]; # shared base: ssh, firewall, ntp
networking.firewall.allowedTCPPorts = [ 80 443 ];
services.nginx = {
enable = true;
virtualHosts."acme.example.com" = {
forceSSL = true;
enableACME = true;
};
};
environment.systemPackages = with pkgs; [ curl jq ];
}Reconstruir un host desde tu laptop o CI es un solo comando:
nix flake check # validate everything
sudo nixos-rebuild switch --flake .#web1
git tag deploy-2026-09-16 # every deploy is versionedBecause the flake lives in git with a lock file, the same configuration that runs today will build identically in a year. That single source of truth is exactly what makes NixOS pair well with the rest of your config-as-code stack — from DNS as code to your IaC of choice.
Deploying a Fleet (and Rolling Back) Like It’s Nothing
For a fresh box, nixos-anywhere bootstraps a full NixOS system over SSH in one shot — no ISO, no interactive installer:
nix run github:nix-community/nixos-anywhere --
--flake .#web2 [email protected]For the fleet itself, deploy-rs is the pragmatic SMB choice: it deploys per-host, runs health checks after activation, and auto-rolls-back on failure:
# deploy.nix
{
deployment.web1 = {
hostname = "203.0.113.11";
profiles.system.path = deploy-rs.lib.x86_64-linux.nixos.profile {
system = "x86_64-linux";
flake = self;
};
autoRollback = true; # undo if the box doesn't come up healthy
};
}deploy . --hosts web1 # deploy one host
deploy . # deploy the whole fleet
deploy . --rollback # back to the last good generationIf your fleet crosses ~20 boxes, look at Colmena, which parallelizes the same flake model across hosts. Either way, the operational payoff is the same one we preach in tool sprawl discussions: one declarative layer replaces your configuration management, packaging story, and rollback tooling at once.
Secretos sin un servidor de secretos
No fleet setup is production-ready without managing secrets. The Nix way is sops-nix: encrypted files in git, decrypted at activation time with an age key on each host. No Vault server, no API to babysit:
# configuration.nix
sops = {
defaultSopsFile = ./secrets.yaml; # encrypted, safe to commit
age.keyFile = "/var/lib/sops-nix/age.key";
secrets.db_password = {}; # decrypted to
}; # /run/secrets/db_passwordsops secrets.yaml # edit with your editor
sops updatekeys secrets.yamlUsing /run/secrets/ paths means secrets aren’t baked into the Nix store, and rotations are a one-line change plus a rebuild. If you prefer per-secret derivation, agenix is the lighter alternative.
¿Es NixOS adecuado para tu PYME? Una checklist de 60 segundos
- You have 3+ Linux VPS that feel increasingly unalike → NixOS will unify them.
- You’ve had a “works on web1 but not app1” incident → NixOS makes that impossible by construction.
- You want rollbacks without snapshot restore theatrics → generations give you instant undo.
- Your team is open to a week of learning Nix syntax → the payoff compounds fast.
- You mostly run Windows/containerless legacy estate → skip it; this isn’t for you.
Empieza pequeño: elige tus máquinas web de front-end, conviértelas una a la vez y mantén el viejo proceso basado en SSH como respaldo hasta que el flake haya demostrado su valía durante un ciclo de release completo. Luego mira cómo tu problema de drift de infraestructura se retira silenciosamente.
Want a second pair of eyes on your server fleet strategy before you commit? Book a free 30-minute DevOps consultation at /reserva-cita and we’ll map out a migration that fits your team.
Español 
English