User data is a script or cloud-init document handed to an instance on first boot. It is how an instance arrives configured rather than bare: packages installed, users created, services started, configuration written.There are two ways to supply it, and they behave differently.
Inline, at deploy time
Registered and reused
Where
The create wizard, and the userData field on the create API
POST /api/v1/userdata/register
Reusable
No — it belongs to that one instance
Yes, by name
Console support
Yes
No
Registered user data has no console screen. The three endpoints below work, but nothing in the interface lists, creates or selects a registered payload. To reuse one you must register it and reference it through the API.The create wizard’s own user data field is inline only — what you type there applies to that deployment and is not saved for next time.
Registered payloads can also be linked to a template, so anything deployed from that image gets them by default — POST /api/v1/templates/{id}/link-userdata. See Templates.
User data runs once, on first boot, as root, with no interactive terminal. That has consequences worth planning for:
A failure is silent. Nothing surfaces in the console. If an instance boots but is not configured, the payload failed, and you find out by reading /var/log/cloud-init-output.log over the console or SSH.
It does not re-run. Fixing a broken script and rebooting changes nothing. You need a new instance, which is why testing on one throwaway machine before a fleet is worth the minutes.
It cannot prompt. Any command that waits for input hangs the boot.
It is not a secret store. Anyone who can read instance metadata can read the user data. Never put credentials in it — fetch them at runtime instead.
Keep the payload small and idempotent: install packages, write configuration, start services. Push anything longer into a script the payload downloads, so you can fix the script without rebuilding the instance.
