Using Kickstart, Preseed, and Cloud-Init

There was a time when installing Linux meant sitting at the console, clicking through every step — language, keyboard layout, disk partitioning, user accounts, package selection. That worked fine for one machine. Maybe even five. But once you had racks of servers or needed rebuilds on demand, it broke down fast.

So the industry started scripting the process.

Red Hat came up with Kickstart, a way to pass instructions to the installer so it could run unattended. Debian and Ubuntu followed with Preseed, using a similar concept — but built around debconf. These tools let you automate the entire OS install: from partitioning to package selection, without needing to touch the keyboard once.

Then came the cloud era — and with it, the idea of booting from prebuilt images. Instead of installing from scratch, you boot into a ready-to-go OS and configure it at runtime. That's where cloud-init enters the picture. It doesn't install the system — it configures it after boot: networking, SSH keys, packages, and more.

Each of these tools solves a different part of the problem:

• Kickstart and Preseed automate the installation process itself
• Cloud-init handles post-install setup and customization
• And depending on how you deploy — ISO, PXE, image — you might use one, both, or all three

Kickstart: Automating RHEL-Based Installs

Kickstart is the go-to for automating installs in the Red Hat ecosystem — RHEL, AlmaLinux, Rocky, and CentOS. It uses a plain-text config file that the Anaconda installer reads to determine how to partition the disk, which packages to install, what users to create, and more.

You typically pass the Kickstart file location through the kernel command line during PXE boot or ISO install:

inst.ks=http://yourserver/ks.cfg

It supports conditional logic, post-install scripts, and can fully automate even complex installs. Partitioning syntax can be a bit picky, and certain options (like bootloader settings or SELinux configs) need to be precisely written, but once dialed in, it's reliable and reproducible.

If you're managing physical servers in a Red Hat-based shop, Kickstart is probably already in play — either directly or under the hood of something like Foreman or Satellite.

Preseed: Automating Debian and Ubuntu Installs

Preseed does the same job as Kickstart, but for Debian-based systems. It works by feeding pre-defined answers to the installer's internal debconf database.

Like Kickstart, the Preseed file is usually passed via PXE or kernel parameters:

auto url=http://yourserver/preseed.cfg

It can handle disk layouts, locales, package selections, even custom commands. But Preseed has a reputation for being a bit fragile — the syntax is sensitive, and sometimes the installer ignores certain directives if things aren't perfectly ordered. You'll often find yourself fighting with obscure options to suppress installer prompts.

Still, with the right config, it works well — especially in environments where Ubuntu or Debian is the standard.

Cloud-Init: Post-Install Configuration

While Kickstart and Preseed handle the actual installation, cloud-init picks up after first boot. Originally developed for cloud platforms like EC2 and OpenStack, it's now widely supported across distributions — and just as useful on bare metal or VM images.

Cloud-init looks for metadata at boot time — things like user accounts, SSH keys, package lists, and system settings. You can provide this data in several formats (NoCloud, EC2-compatible, etc.) and deliver it via attached ISO, HTTP endpoint, or your provisioning platform.

It's perfect for image-based workflows — for example, if you PXE boot into a prebuilt Ubuntu image, cloud-init can take care of final customization.

Important note: cloud-init doesn't install the OS. It configures a system that's already been installed — or one booted from a full image.

When to Use What (And How They Work Together)

Let's make this clear:

You'll typically pick one of Kickstart or Preseed depending on your distro, and optionally combine it with cloud-init to do post-install setup.

For example:

• PXE boot into an Ubuntu installer using Preseed
• After install, the image boots — and cloud-init finishes configuration

Or:

• Provision a Rocky Linux server with Kickstart
• Use a post-install script in Kickstart to inject cloud-init and hand it control for future boot-time customization

Modern bare metal platforms (like Cycle.io or MAAS) often tie all of this together behind the scenes — but even if you're not writing the configs by hand, it's worth understanding what's happening under the hood.

Know Your Layer

There's no single tool that does it all. Instead, think of Kickstart, Preseed, and cloud-init as layers in your provisioning process:

• Kickstart and Preseed get the OS onto the disk
• Cloud-init takes care of what happens after it boots

Knowing where each one fits — and how to use them together — is key to building fast, repeatable, hands-off installs for any Linux system you deploy.