Build a Headless Debian or Ubuntu Server Image

A reliable headless image needs more than an unattended installer. The useful contract is: the machine boots without a GUI, accepts the right remote access, starts its workload, exposes only the intended network services, and passes the same checks after reboot.

Debian and Ubuntu already provide solid installer automation. The Debian installer supports preconfiguration files that answer installer questions, as documented in the official Debian preseeding appendix. Ubuntu Server 20.04 and later supports YAML-based autoinstall configuration, and current Ubuntu Desktop installers support it as well. Canonical's autoinstall introduction explains how configuration can answer installation questions without interaction.

Those mechanisms solve installation. An image workflow must also solve specification, repeatability, boot validation, and release evidence. That is the layer this guide focuses on.

1. Write the machine contract first

Begin with observable requirements, not a package list. The following example is specific enough to test:

Base: Debian stable, amd64
Role: headless reverse-proxy node
Access: SSH key only for operator; root login disabled
Network: DHCP; expose TCP 22, 80, and 443 only
Services: nginx enabled at boot
Storage: persistent data mounted at /srv
Updates: unattended security updates
Acceptance: boot, SSH, HTTPS health check, clean reboot

For Ubuntu, the same contract may be expressed through autoinstall identity, SSH, storage, package, and late-command sections. For Debian, preseed covers localization, networking, account setup, partitioning, package selection, and boot-loader installation. In OpenFactory, the contract becomes the starting point for a recipe and its tests.

2. Keep the image truly headless

Avoid installing a desktop task or display manager unless the system actually needs one. Set the default systemd target to multi-user.target. Use a serial console for recovery where the target platform supports it. Treat SSH configuration as a security control: place an explicit public key, disable password authentication when practical, and decide whether any direct root access is allowed.

Headless does not mean unobservable. Include the logs, metrics, health endpoint, or management agent needed to diagnose a system after deployment. A minimal image that cannot explain a failed first boot is expensive to operate.

3. Test the booted server

Test from outside the guest when possible. An internal curl localhost check proves less than a request from another machine through the intended network path. Likewise, checking that an SSH process exists is weaker than proving that the expected key can log in and an invalid method cannot.

4. Preserve installer and runtime evidence

Keep the recipe, installer input, package versions, build result, test output, and release identifier together. Record which base release was used and when the security package set was resolved. If a later image behaves differently, that lineage narrows the investigation.

OpenFactory turns this into a short feedback loop: describe the headless role, build it, boot the real VM, attach checks, and refine the same recipe. Start from the Linux builders funnel or browse existing systems before creating one from scratch.