Standard NixOS deployments can be resource-intensive, often requiring over 1GB of RAM to complete a system rebuild without encountering Out-Of-Memory (OOM) errors. For users running on low-end virtual private servers (VPS) with limited resources, such as 512MB of RAM, these requirements can be a significant barrier. By aggressively optimizing the kernel and userland components, it is possible to reduce the idle footprint to approximately 96MB and ensure that the `nixos-rebuild` process completes successfully within a 512MB limit.
The optimization process begins at the kernel level by stripping away hardware support that is irrelevant to a KVM guest. This includes blacklisting drivers for floppy disks, USB devices, and various input methods, as well as disabling kernel profiling and audit threads. A critical step involves pruning the kernel module tree; by using a custom derivation to remove drivers for sound, GPU, and physical NICs, the module tree can be reduced from 162MB to 45MB on disk. Additionally, disabling Transparent Huge Pages (THP) can free up significant amounts of reserved memory—in some tests, this alone freed over 50MB of non-cache memory by lowering the `vm.min_free_kbytes` threshold.
In the userland, memory is saved by replacing heavy systemd services with lightweight alternatives. For example, swapping `systemd-resolved` (which uses about 8.3MB of resident memory) for a plain `resolv.conf` and replacing `systemd-timesyncd` with a `busybox ntpd` one-shot timer reduces the persistent memory overhead. Furthermore, enabling socket activation for SSH ensures that the SSH daemon only consumes memory when an active connection is established. To handle the memory spikes during a rebuild, the system can use `zram` with `zstd` compression, paired with specific kernel tunings like `vm.swappiness = 180` and adjusted `watermark_scale_factor` to ensure the kernel prioritizes compressing cold pages rather than discarding the page cache.
While these optimizations allow for stable daily operation and standard updates, they do introduce specific limitations. The most notable constraint is the difficulty of performing major release jumps (e.g., moving from one stable release to an unstable branch). Because these jumps can cause massive peak memory spikes during the build process, they may still trigger OOM errors on 512MB systems. In such cases, users may need to provide additional RAM temporarily or perform the update in multiple stages, as the peak memory required for a full release jump can exceed the capacity of a highly stripped environment.