Preseed and Autoinstall: automating Ubuntu Server deployments

The challenge of managing hundreds of manual servers

Imagine you have been given the task of setting up fifty powerful computers, known as servers, to run business applications. Doing this by clicking through screens and typing commands one by one on each machine is like building a house by placing every brick by hand without an organized blueprint. In technology, we call this manual repetition an operational bottleneck because it wastes time and invites simple human errors, such as forgetting to enable a security rule.

To solve this problem, infrastructure engineering uses automation right from the root, meaning from the moment the operating system is installed onto the hard drive. Instead of a technician answering questions on a black screen during bootup, we prepare a detailed script of instructions that the computer reads on its own. In practice, this means we turn on an empty machine and it configures itself entirely from scratch, ready for use, without anyone needing to touch the keyboard.

The technical evolution: from legacy models to modern standards

Historically, the Linux community used a system called Preseed to automate these installations using plain text files with pre-configured answers. Although it worked well, the format required complex lines that were difficult to read for beginners. With the arrival of recent Ubuntu Server releases, Canonical introduced the concept of Autoinstall, which uses YAML, a markup language focused on human readability and clear data structuring.

This transition represented a massive qualitative leap for tech teams because it made configuration files clean and easy to audit. A YAML file uses space indentation to organize blocks of information, resembling a well-organized shopping list. In practice, any engineer or administrator can open the file and immediately understand which software packages will be installed and which disk partitions will be created without decoding cryptic codes.

Anatomy of an automated configuration file

For the magic to happen, we need to structure a text file containing all the decisions we would normally make by clicking through visual menus. The Autoinstall file is divided into logical sections such as language, keyboard layout, network configuration, and access credentials. Each of these sections answers in advance the questions that the traditional installer would ask during the process.

Below is a functional snippet of a YAML file used to automate initial network setup and create a default administrator user:

#cloud-config
autoinstall:
  version: 1
  identity:
    hostname: production-server-01
    username: administrator
    password: '$6$rounds=4096$example$H9V6K...encrypted_password_here...'
  locale: en_US.UTF-8
  keyboard:
    layout: us
  ssh:
    install-server: true
    allow-pw: false

In the code block above, we define the machine name, create the primary user, and configure secure remote access via SSH key, blocking plain passwords for security. This level of detail ensures the server is born hardened against common intrusions right on the first boot, without requiring subsequent manual tweaks.

Automating disk partitioning and storage

One of the most critical points in any server installation is how the hard drive is partitioned to store the operating system, log files, and application data. Mistakes in partitioning can lead to a lack of space for future system growth. With Autoinstall, we describe this storage architecture directly in code, ensuring that partitioning is identical across all machines in the fleet.

Storage configuration defines which disks receive the partition table, the size of each reserved space, and the file system used, such as ext4 or modern ZFS for greater fault resilience. In practice, this eliminates the risk of a technician selecting the wrong disk during installation and accidentally deleting important data, as the process is entirely deterministic and software-controlled.

The provisioning lifecycle: delivering the image to the server

Creating the configuration file is only half the battle; the other half involves delivering that file to the Ubuntu installer when the machine boots up. There are several ways to do this, the most common being creating a custom installation media, such as a USB flash drive or a modified ISO image that already embeds the response file.

Another widely used enterprise approach is network provisioning via PXE servers, where the computer fetches the system image and configuration file directly over the local network as soon as it powers on. This method is essential in data centers with hundreds of physical servers because it allows updating or reinstalling an entire machine just by rebooting the equipment remotely, without physical media.

Validating and testing the workflow before production

Making syntax errors in an infrastructure configuration file can break the installation process halfway through, leaving the server unreachable. Therefore, experienced professionals use local validation tools, such as YAML syntax checking utilities and virtual machine simulation environments before applying any scripts to real servers.

Tools like QEMU or Multipass allow running the Ubuntu installer in an isolated environment inside your own laptop to test if the response file works from start to finish. In practice, this homologation step saves hours of frustration and ensures real infrastructure receives only tested and approved code.

Final thoughts on infrastructure standardization

Adopting automated workflows with Preseed and Autoinstall transforms how we handle server infrastructure, replacing repetitive manual labor with reliable software engineering. By treating operating system installation as version-controlled code, projects gain speed, traceability, and consistency at any scale.

Investing time in creating these scripts pays off quickly the first time a server needs to be rebuilt from scratch due to hardware failure. Instead of hours of stressful work, recovery boils down to a few minutes of autonomous processing, proving that well-done automation is the best ally of operational stability.