All free tools Generated in your browser

Cloud-init Generator

Describe how a new server should come up and get a #cloud-config user-data file to paste into your provider at create time.

FIRST BOOT CONFIGURATION

Build a cloud-config file

user-data
System identity
Letters, digits, hyphens, and dots. If you enter a full domain such as web01.example.com, the file sets fqdn to that value and hostname to web01. Leave empty to keep the name your provider assigns.
An IANA zone in Area/City form, such as Europe/London or Asia/Kolkata, or the value UTC. List them on any Linux host with timedatectl list-timezones.
A locale name such as en_GB.UTF-8 or en_US.UTF-8. Leave empty to keep the image default.
Users and SSH keys
Every account is written with lock_passwd: true, so it has no usable password and can only be reached with one of the keys you list. This tool never asks for a password and never writes one. Leave a block empty to skip it.
SSH access

A wrong key locks you out of the new server. With root login disabled, password authentication off, and locked accounts, the public keys you paste are the only way in. Check that each key matches a private key you actually hold, and keep the provider console or a rescue option available for the first login.

Packages
One package name per line, using the names your distribution uses. Lower-case letters, digits, and + . _ - only.
Firewall
Comma separated. Use a UFW application name such as OpenSSH or Nginx Full, a port such as 80, a port with a protocol such as 443/tcp, or a range such as 60000:60010/udp. The rule that allows SSH is written first.
Files to write
Each entry becomes a write_files block. Files are written before runcmd runs, so a script you write here can be called by a first-boot command below.
First-boot commands
One command per line, run as root once at first boot. Any firewall commands are placed before these. Keep each line to a single command; there is no interactive shell and no prompt to answer.

Cloud-init runs once, at first boot. A mistake in this file is not something you can fix by editing it afterwards: you normally have to rebuild the server. Test the file on a disposable instance before you use it for anything real, and keep console access available.

We do not store your data. Hostnames, usernames, public keys, and file contents are validated and rendered into YAML entirely in your browser. Nothing you type is sent to VPSLake.

HOW TO USE IT

From form to a ready server

Have your SSH public key to hand before you start. On your own machine it is normally in ~/.ssh/id_ed25519.pub.

  1. 1

    Set the name and the accounts

    Enter a hostname, then add one user per person or per deployment role. Paste the matching public key into the key box; the account is written with no usable password, so the key is the only way in.

  2. 2

    Choose packages, firewall, and files

    List the packages the server needs, decide whether UFW should come up with SSH allowed, and add any configuration file the machine should start with.

  3. 3

    Generate and read the file

    Select the generate button and read the YAML. The first line must be #cloud-config; cloud-init ignores the whole file without it.

  4. 4

    Paste it in when you create the server

    Copy the file into the user data field your provider shows on the create page, then create the instance. Once it boots, run cloud-init status --wait to see when it has finished and read /var/log/cloud-init-output.log for what each step did.

What a cloud-config file is

Cloud-init is the program almost every Linux cloud image runs on its very first boot. It reads the user data your provider passes in and applies it before you ever log in. A user-data file that begins with the line #cloud-config is treated as YAML instructions rather than as a shell script, which is what this tool produces.

Keys are written in the order cloud-init applies them, so the file reads in the same sequence the machine executes.

  • hostname, fqdn, preserve_hostname, timezone, and locale
  • users with lock_passwd, shell, groups, sudo rule, and ssh_authorized_keys
  • disable_root and ssh_pwauth, always written explicitly
  • package_update, package_upgrade, and a packages list
  • write_files with path, permissions, owner, and block-scalar content
  • runcmd for firewall rules and your own first-boot commands
  • An optional power_state reboot once everything has finished

Its limits, and where it can go wrong

User data is consumed once, at the first boot of a fresh instance. Editing the file afterwards changes nothing, and pasting it into an existing server does nothing at all. If the result is wrong, the normal fix is to destroy the instance and create a new one with a corrected file.

The generator cannot check anything about the target image. It does not know whether a package name exists in that distribution's repositories, whether a group such as docker is present before your user is created, whether the ufw package is installed, or whether your public key is the one you still hold the private half of. Each of those is a common cause of a first boot that finishes with errors.

Defining a users list also replaces the image's default account. On an Ubuntu image that means the usual ubuntu user is not created unless you list it yourself. That is normally what you want, but it is worth knowing before the first login attempt.

Treat the output as a reviewed starting point rather than an audited configuration. Read it, adapt it, and try it on a disposable instance first.

Test on a server you are willing to throw away

This file decides who can log in to a brand-new machine. With disable_root: true, ssh_pwauth: false, locked passwords, and a firewall that comes up enabled, a single wrong public key or a missing SSH rule leaves you outside the server with no way back except the provider console or a rebuild. Create one cheap instance with the file first, confirm that you can log in and that cloud-init status reports done, and only then use it for real work. Keep the console open during the first boot of any machine that matters.

FREQUENTLY ASKED QUESTIONS

Cloud-init Generator FAQ

Into the user data field on your provider's create-server page. It is usually near the SSH key selector and may be labelled user data, cloud-config, cloud-init, or startup script. Paste the whole file including the first line. On a local hypervisor the same content goes into the NoCloud user-data file on the seed image, and with cloud-localds it is the input file. It has to be present before the first boot.
Cloud-init decides how to handle user data from its first line. #cloud-config means the rest is YAML configuration; #!/bin/bash means it is a script to execute. Without a recognised first line the data is ignored, and the only sign is a line in /var/log/cloud-init.log. A blank line, a comment, or a stray space before it is enough to break the file, so keep it exactly as generated.
No. The modules used here run once per instance, so a normal reboot repeats nothing. Cloud-init keeps its state in /var/lib/cloud, and clearing it with sudo cloud-init clean --logs before a reboot makes the machine treat itself as new and run the file again. That is useful when you are testing a file, but it is disruptive on a live server, and any user data change still requires a new instance.
Every key used here has been supported for many releases and works on current Ubuntu, Debian, Rocky, AlmaLinux, and Fedora cloud images, which all ship cloud-init. Package names differ between families, so a list written for Ubuntu will not apply cleanly on a Red Hat derived image. Check the installed version with cloud-init --version, and validate a file before use with cloud-init schema --config-file user-data.yaml.
Because user data is not a safe place for one. It is readable from inside the instance through the metadata service, and providers commonly show it in the console and keep it in their own logs. The generator therefore writes lock_passwd: true for every account and never asks for a password. If you genuinely need console access with a password, set it after first boot with sudo passwd <user>.
Log in through the provider console and run cloud-init status --long. done means it finished, error means a module failed, and disabled usually means the image found no user data. Then read /var/log/cloud-init-output.log, which holds the visible output of package installs and every runcmd line, and /var/log/cloud-init.log for module-level detail. A YAML mistake is normally reported near the top of the second file.
The tool checks that the hostname uses only letters, digits, hyphens, and dots, that a username matches [a-z_][a-z0-9_-]{0,31}, that each SSH key line starts with a supported key type followed by a base64 blob, that package names are lower-case, that a path is absolute, that permissions are three or four octal digits, and that the time zone is in Area/City form. It also refuses control characters everywhere and line breaks in any value that has to stay on one line, so a stray newline cannot inject a second YAML key.
It does not talk to your provider, create servers, or validate anything against a real image. It leaves out passwords and password hashes, chpasswd, extra apt or yum repositories, disk partitioning and growpart, mounts, network configuration, Ansible or Puppet handoff, and multi-part MIME user data. Those either need knowledge of the target image or carry more risk than a form can manage. Add them by hand once the basic file works.
No. The page loads one small script that validates the fields and assembles the YAML locally. There is no upload, no analytics capture of the form, and no storage of what you enter. Closing the tab discards everything. A public key is not secret in any case, but a private key should never be pasted into any web page, including this one.