Cloud-Init: Servers That Configure Themselves

What it can do on first boot

• Create users, add SSH keys, configure sudo.
• Set the hostname and timezone.
• Update package lists and install packages.
• Write arbitrary files with specific permissions.
• Configure the firewall.
• Mount and format additional volumes.
• Run shell commands in a defined order.
• Reboot when finished, if needed.

That covers the entire manual checklist most people run after creating a server, which is the point.

A sensible starting configuration

A useful cloud-config typically does the following, in this order:

1. Create a non-root user with your public key and passwordless sudo.
2. Disable SSH password authentication and root login.
3. Update all packages.
4. Install the essentials: a firewall, fail2ban, unattended-upgrades, and your runtime.
5. Enable and configure the firewall with a default-deny inbound policy.
6. Enable automatic security updates.
7. Write any configuration files the services need.
8. Start services.

Written once, this produces an identically configured server every time, in about ninety seconds, with no opportunity to forget a step.

The rules that avoid frustration

• It runs once, on first boot. Changing user data later does nothing to an existing instance.
• Validate the YAML before creating the instance. A syntax error means a server that boots and does nothing you asked for.
• Check the logs at /var/log/cloud-init-output.log when something did not happen.
• Order matters — runcmd executes after packages are installed, which is usually what you want.
• Never put secrets in user data. It is readable from instance metadata by anything on the machine.
• Keep it idempotent where possible, so re-running by hand is safe.

The secrets rule is important. User data is not a secure channel; fetch secrets at runtime from a secret manager using the instance identity instead.

When to move beyond cloud-init

The common progression: cloud-init for the base, then a baked image once boot time matters, with cloud-init handling only per-instance specifics such as hostname and role.

Baked images

Building a custom image with everything pre-installed — using Packer or the provider’s snapshot feature — cuts boot time from minutes to seconds and removes dependency on package repositories being available at boot.

1. Start from the provider’s base image.
2. Apply your cloud-init configuration and install everything.
3. Remove machine-specific identifiers such as SSH host keys and machine-id.
4. Snapshot it, versioned with a date or commit.
5. Use cloud-init at launch only for the small per-instance differences.
6. Rebuild the image on a schedule so security patches are included.

That last step matters. A baked image that is never rebuilt becomes a security liability the moment the base has patches.

Common questions

Where to go next

See the first hour on a new cloud server and infrastructure as code.