NixOS on a VPS: Why It's Worth Trying and How to Get Started

Most people who know NixOS have written it off as a hobby operating system. Too academic, too opinionated, built by people who find joy in things the rest of us avoid. That reputation is mostly earned on the desktop side. On a server, and specifically on a KVM VPS, NixOS is one of the most practical choices you can make. I say this having run it in production and having also broken it spectacularly a few times. The breakage is the point, and I will explain why.

What Makes NixOS Different

The entire system configuration lives in a single file. Every package, every service, every open port and firewall rule is declared there. When you provision a NixOS VPS and run a service, you are not running a series of commands that mutate system state and then hoping you remember what you did six months later. You are writing down what you want the system to look like, and NixOS makes it so.

This matters most when something goes wrong, or when you need to reproduce an environment. If you want an identical server to the one you have, you copy the configuration file and run one command. If a colleague needs to understand what is running on the server, they read the configuration file. There is no history of manual changes to reconstruct.

The configuration is also version-controllable, which sounds obvious once you hear it but is genuinely transformative in practice. Commit your configuration.nix to a git repository. Every change is tracked, every rollback is documented, and you have a complete audit trail of everything the system ever was.

The Rollback Story

Here is the part that actually sold me. If you push a bad configuration and the system becomes unresponsive or broken, you do not reinstall. You do not boot into rescue mode. You reboot the machine and select the previous generation from the bootloader menu. NixOS keeps every previous system configuration as a bootable option, and switching back takes about thirty seconds.

I have done this. I misconfigured a firewall rule, locked myself out over SSH, and fixed it from the portal console in under two minutes. On a traditional Linux system that same mistake would have required a reinstall or a long session in recovery mode. On NixOS it was a minor inconvenience.

Even without a reboot, you can roll back immediately from the command line. The previous generation is always there waiting. This changes how you think about making changes to a production server, and it changes it for the better.

Getting Started on RackWorks

The reputation NixOS has for being difficult to install is accurate for bare metal. You need to partition disks, configure bootloaders, and handle hardware drivers. It is a real learning curve and most tutorials assume you already understand it.

On RackWorks, none of that applies. NixOS is available in the OS selector when you provision a KVM VM. You pick it, provision, and have a running NixOS system with SSH access in a few minutes. If you decide after a week that it is not for you, you reinstall from the portal to whatever else you want. The only downside is the standard reinstall notice about disk contents, which applies to every OS reinstall regardless of what you are switching to.

The First Few Commands

Once you SSH in as root, the system is fully functional. The configuration file is at /etc/nixos/configuration.nix. It already has your hostname, your timezone, and SSH configured, because those settings were applied at provisioning time.

Adding a service means editing that file. To enable nginx and open the relevant firewall ports, add these two lines inside the top-level curly braces of the configuration:

services.nginx.enable = true;
networking.firewall.allowedTCPPorts = [ 80 443 ];

Save the file and apply the change:

sudo nixos-rebuild switch

NixOS builds the new configuration, activates it, and starts nginx. The previous configuration is kept as a generation you can return to at any time. To see what generations you have available and roll back to the previous one:

sudo nix-env -p /nix/var/nix/profiles/system --list-generations
sudo nixos-rebuild switch --rollback

The rollback applies immediately without a reboot. If you prefer to select a specific older generation, reboot and choose it from the bootloader menu. Both approaches work and both get you back to a known-good state in under a minute.

Adding packages follows the same pattern. Add the package name to the environment.systemPackages list in the configuration file, run nixos-rebuild switch, and it is available system-wide. Remove it from the list and rebuild, and it is gone. There is no orphaned dependency cleanup, no wondering whether a package left something behind.

Who This Is Actually For

NixOS is a good fit if you care about reproducible infrastructure and are comfortable on the command line. Developers who want their local and server environments to match will benefit immediately. People who are already running NixOS locally and want the same setup on a public VPS will feel at home from the first SSH session.

It is not the right choice if you are just getting started with Linux and need a familiar system to experiment on. Ubuntu and Debian exist for that and they are good at it. NixOS assumes you know what a service unit is and have opinions about how your firewall should be configured.

The target user is someone who has, at some point, broken a server with apt upgrade and had to spend a weekend fixing it. That person will understand immediately what NixOS is solving.

Worth Trying

NixOS is available in the OS selector right now on any KVM plan at RackWorks. Provision one, read through the configuration file, add a service or two, and see if the mental model makes sense to you. The worst outcome is you reinstall to something else and lose nothing but the time it took to try. The best outcome is that you stop managing servers by running a series of commands that nobody wrote down and start managing them like the auditable, version-controlled systems they should be.