Your own cloud-init

Cloud-init is the first thing that runs on a new server. You can hand it a document of your own when you start one, and the machine comes up with your packages installed, your files in place and your commands run, instead of a bare system you still have to set up.

Write one

A document starts with the line #cloud-config and is YAML underneath:

#cloud-config
packages:
  - htop
  - ufw
write_files:
  - path: /etc/motd
    content: |
      This machine belongs to the search team.
runcmd:
  - [ufw, allow, 22/tcp]
  - [ufw, --force, enable]

When you configure a server, open Advanced deployment options, switch on Cloud-init and paste it in the field Cloud-init document. It is optional and it is at most 16 kB; anything longer belongs in a script the machine fetches on its first boot.

What we add ourselves

Whatever you write, we put these on top of it:

Setting	Why
`hostname` and `preserve_hostname`	So the machine carries the name you gave it
`ssh_authorized_keys`	The keys you chose when ordering, beside any you wrote yourself
`disable_root`	So the key you ordered with can actually be used
`timezone`	The time zone you chose in the order, unless your document names one itself
`qemu-guest-agent` under `packages`, and a command in `runcmd` that starts it	The small program that lets the console give root a new password. It comes from the package sources of the system, so the server has to reach those on its first boot
An entry in `bootcmd` and a command in `runcmd`	So the package step of the first boot fetches over IPv4, after your own early commands
`ssh_pwauth: false` and a last command in `runcmd`	You chose keys only, so password login over SSH is switched off and the root password is locked, after everything else has run. Ask for a password in your own document (`ssh_pwauth: true`, `password`, `chpasswd` or a user with a password) and we leave it as you wrote it. A new root password from the console still works on the console screen
`ssh_pwauth: true` and a last command in `runcmd`	Instead of the row above, when you ticked E-mail me the root password: password login over SSH is switched on, for root as well. The password is never in the document as text

This is on purpose. A document that forgets the keys, or renames the machine halfway, would leave you locked out of a server you just paid for.

When it runs, and when it does not

It runs once, on the first boot of a new server. Changing the document afterwards changes nothing on a machine that already exists.
Rebuilding a server does not run it again. A rebuild gets our part again (the name, your keys, the time zone, the guest agent and the password rule), not your own document. Everything else you want, you run yourself.
A mistake in the document does not stop the server from starting. Look in /var/log/cloud-init-output.log on the machine to see what happened.

Refused before you order

We read your document before the order is taken, so a mistake costs you nothing:

It has to start with #cloud-config. A shell script (#!/bin/sh) cannot be combined with the part we add.
It has to be readable YAML, and it has to be a list of settings, not a plain list.

Save a script to use again

Under Compute tools, User scripts in the console you can save a cloud-config with a name and a description. When you order a server, choose it under Start from a saved script; the order then gets its own copy, so changing the saved script later does not change servers that were already built with it.