nixvps

NixOS on sub-1GB VPSes, down to a 256MB floor

The receiver side of a tiny-VM deployment stack: reusable NixOS modules for nodes from 256MB to 1GB RAM. Includes conservative base profiles (tiny-vm, nano), signed delivery (pull-update, deploy-target), and image-baking for boot-from-prebuilt instead of install-on-first-boot. The producer side (build, sign, publish) is deliberately out of scope — bring your own CI via the BUILD-CONTRACT.

Status: pre-alpha, modules real

!

Five modules exist today

Below is exactly what exists: tiny-vm, nano, pull-update, deploy-target, and image-bake. All five are real and functional; nothing advertised here is missing or placeholder.

!

Being extracted and generalized

These modules were developed and used in production. Pulling them into a general-purpose, documented project is in progress. They carry no site-specific defaults, but are still new and lightly documented.

!

No invented benchmarks

Nothing on this page claims a tested MB number or specific performance result. We target the 256MB–1GB class honestly. Everything under Roadmap is future work, clearly marked as such.

Five receiver-side modules

tiny-vm.nix

A conservative baseline profile for the ~1 vCPU / ~1 GB RAM class: btrfs mount tuning, bounded journald, clamped nix-daemon (max-jobs, cores), automatic GC, and capped boot-loader generations. Every setting is a lib.mkDefault, so overrides are painless.

nano.nix

An even tighter profile targeting the 256MB–512MB class: serial builds only, aggressive journal limits, minimal systemd units, and constant-memory monitoring. Designed for the absolute floor of tiny-VM viability.

pull-update.nix

Autonomous, reboot-less, pull-based self-update for unreachable nodes. On a timer, the node fetches a signed closure pointer, verifies it, switches live, runs a local health check, and rolls back on failure. No reboot anywhere in the cycle.

deploy-target.nix

The passive receiver: configures a node to trust a signed binary cache and accept inbound deploys via SSH. No timers, no polling, no health checks of its own — just trust setup. Use alone for push-deployment, or with pull-update for hybrid nodes.

image-bake.nix

Bake a bootable disk image instead of install-on-first-boot. Lets you boot from a pre-built, signed image directly, skipping the build step entirely on the target VM. Targets common image formats for cloud providers.

Deliberately out of scope

The producer side

Building, signing, and publishing closures or images is outside nixvps. Bring your own CI, binary cache, and signing setup via the BUILD-CONTRACT. nixvps is the receiver: configure a node to pull and trust.

Memory-pressure tuning

Deep zram / zswap / OOM-killer engineering belongs to the sibling nixram project. nixvps assumes that layer is already handled.

Roadmap

1 GB-RAM base profileConservative daemon defaults, clamped nix.settings. Donemodules/tiny-vm.nix.
256MB-floor profileMinimum viable for the absolute tiny class. Donemodules/nano.nix.
Pull-based self-updateSigned closure fetch, live switch, health-check rollback. Donemodules/pull-update.nix.
Deploy-target moduleTrust signed cache, accept signed deploys. Donemodules/deploy-target.nix.
Image-bake moduleBoot-from-prebuilt instead of install-on-first-boot. Donemodules/image-bake.nix.
Example configurationMinimal flake wiring all five modules end to end. In progress.
Documentation and quickstartReal usage guide once examples are complete. Planned.