Andrew Mercer
on this page

Autoinstall is Ubuntu Server's unattended-install format, used by the Subiquity installer since 20.04. It replaced the Debian-installer/preseed approach on Ubuntu (Debian itself still uses Preseed) and is built directly on cloud-init's user-data mechanism, which is why its syntax looks like cloud-init rather than like Kickstart.

Structure

An autoinstall config is YAML under an autoinstall: key, typically delivered as cloud-init user-data:

#cloud-config
autoinstall:
  version: 1
  locale: en_US.UTF-8
  keyboard:
    layout: us
  network:
    network:
      version: 2
      ethernets:
        eth0:
          dhcp4: true
  storage:
    layout:
      name: lvm
  identity:
    hostname: server01
    username: admin
    password: "$6$roundsaltedhashhere"
  ssh:
    install-server: true
    authorized-keys:
      - ssh-ed25519 AAAA...
  packages:
    - chrony
    - vim
  late-commands:
    - curtin in-target -- systemctl enable chronyd
  user-data:
    disable_root: true

Key sections, at a glance:

Key Purpose
storage partitioning/LVM layout — lvm, direct, or a full custom config: list
identity hostname, primary user, password hash
ssh install openssh-server and seed authorized keys
packages extra packages beyond the base install
early-commands / late-commands shell commands run before/after install (roughly Kickstart's %pre/%post)
user-data passed straight through to cloud-init for first-boot config on the installed system

Interactive sections and confirmation

By default, any section you don't specify falls back to interactive prompts. Add interactive-sections: [] to make everything unattended, or list specific sections (e.g. interactive-sections: [network]) to leave just those prompted. For fully hands-off installs on real hardware, autoinstall also normally shows a final confirmation prompt unless you boot with the autoinstall kernel parameter (see below), which is a deliberate safety guard against accidentally wiping a disk from a config meant for a different machine.

Validate before using

sudo snap install subiquity --classic     # or: sudo apt install subiquity (varies by release)
python3 -c "import yaml, sys; yaml.safe_load(open('autoinstall.yaml'))"   # basic YAML sanity check
cloud-init schema --config-file autoinstall.yaml                          # validates the cloud-init/autoinstall schema itself

Delivering the config

# Local ISO build (nocloud datasource via a second attached volume/ISO)
# a genisoimage-built "cidata" volume containing user-data + meta-data, attached as a CD-ROM

genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data

# Boot the Ubuntu Server ISO with the autoinstall kernel parameter and a datasource pointing at the seed:
# autoinstall ds=nocloud;s=/cdrom/    (when the seed is a second attached ISO)
# autoinstall ds=nocloud-net;s=http://<server>/autoinstall/    (served over HTTP, good fit for PXE)

The ds=nocloud-net;s=http://... form is the one that pairs cleanly with PXE/netboot: the installer fetches user-data and meta-data from that HTTP path the same way it would from a cloud-init metadata service.

Relationship to cloud-init

Autoinstall's user-data: block (nested inside the autoinstall document) is handed to cloud-init verbatim once the base OS is installed and boots for the first time — so anything you'd normally configure with plain cloud-init (extra users, write_files, runcmd) works there too. Think of Autoinstall as "cloud-init's config format, extended with a storage/network/identity vocabulary for driving the actual OS installer," rather than a separate, unrelated tool.