SilverStack
Preconfigured servers as Firecracker microVM playgrounds
SilverStack is an open, ongoing project of mine: complete, preconfigured machines packaged as custom OCI rootfs images and published as playgrounds anyone can launch in a browser on iximiuz Labs, which boots each one as a Firecracker microVM. Seven images so far, five live as playgrounds. systemd runs as PID 1 in every one, and machines serving a public URL reach it through an outbound-only Cloudflare Tunnel from behind CGNAT, no inbound port ever opened. Each image is built and pushed to GHCR by its own GitHub Actions workflow, and every service image must pass a build-time health check first. The current set is developer and CI/CD focused because that was needed first.
What is published
Dev Machine: a fully provisioned Ubuntu 24.04 DevOps workstation, every tool pre-installed and every alias pre-wired. My primary daily machine.
Jenkins Server: Jenkins LTS, systemd-booted, Nginx-proxied, Cloudflare-ready.
SonarQube Server: SonarQube 26.2 CE (LTA), PostgreSQL-backed.
Nexus Server: Nexus Repository Manager 3 Community Edition.
CI/CD Stack: all three services plus a jump host, four machines in one playground on a shared private network.
Two further images exist: the shared ubuntu-24-04 base, and an Apache Guacamole desktop (MariaDB, guacd, Tomcat 10, XRDP, Nginx) for browser-based RDP. Guacamole is built and CI-published, not yet released as a playground.
Why a custom rootfs
iximiuz Labs runs playgrounds as full microVMs, not containers, booting from a root filesystem mounted at /. The default approach runs install scripts on every start, so every visitor waits. A custom rootfs removes that wait: everything is already in the image, pushed to a public OCI registry and referenced as the VM drive source. Zero install time, instant prompt.
Both are an OCI image. Only one is a machine.
A container borrows the host's kernel and gets one process started for it. A microVM is handed a kernel and has to bring itself up from there. A playground root drive has to be linux/amd64, carry no kernel, ship an init system, run sshd on 0.0.0.0:22 at boot, and already contain its users. No CMD or ENTRYPOINT is read at all, since the platform boots /lib/systemd/systemd itself.
Services are enabled at build time, never started: no init system runs during docker build, so systemctl enable writes a symlink into multi-user.target.wants/ that systemd reads on the next real boot.
/etc/machine-id is emptied so each VM generates its own systemd identity. SSH host keys are deleted too: left in, every VM booted from that image would share one identity. iximiuz Labs regenerates host keys at first boot anyway, so this is defence in depth here, but not optional on my own Firecracker or Cloud Hypervisor.
/run is tmpfs and wiped on every reboot, so a lab-init oneshot rebuilds what sshd and nginx need on each boot rather than once at instance creation. That same unit does the runtime work an image should not carry: creating PostgreSQL and MariaDB databases, importing schemas, injecting credentials, and tuning kernel parameters such as vm.max_map_count for SonarQube's Elasticsearch. Every image takes Docker build arguments, so usernames, ports and domains are set at build time.
No public IP, no inbound ports
The machines sit behind Carrier-Grade NAT, by design rather than as a flaw to work around. A service needing a persistent custom domain with SSL gets two components baked in: Nginx, reverse-proxying port 80 to the service's internal port, and cloudflared, opening an outbound tunnel at boot with automatic SSL. Images with no public URL carry neither. Nginx also runs a /health endpoint and hardened security headers.
Publishing and access
GHCR is a requirement, not a preference: the drive image must be publicly pullable and cannot live on Docker Hub, which rate-limits pulls. A manifest pointing at Docker Hub, or a private image, fails at playground start rather than at build.
Every service image runs a build-time health check before it can be pushed: nginx -t parses the real config, systemd units are verified by their multi-user.target.wants symlink, and required binaries and directories are asserted present. A nonzero exit fails the build.
Access is least-privilege throughout: strict sudoers profiles, daemon user isolation, ephemeral SSH keys per microVM instance, and third-party binaries pinned to specific versions and verified by SHA256 checksum.
Interactive tutorial
A tutorial on iximiuz Labs builds a container image and a bootable rootfs from the same Dockerfile: where the two diverge, what a plain ubuntu:24.04 is missing, and how to prove an image would boot without booting it.
Links
Built with
