Skip to main content

VM Templates and Cloud-Init in Proxmox VE: Fast Deployment

Proxmox VE · 29.09.2026

What a VM Template Is and Why Cloud-Init Matters

A template in Proxmox VE is a ready-made virtual machine blueprint that lets you quickly clone new VMs without reinstalling the operating system. Cloud-init is a standard for configuring cloud images at first boot: it sets the hostname, network, user, and SSH key before the system fully starts up.

Together, a template and cloud-init turn deploying a server into a one-minute operation: clone the template, pass in the network and key parameters, start the VM — it configures itself on first boot. This is especially useful when mass-creating virtual machines with the same base configuration.

How to Prepare a Cloud Image for the Template

A template uses not a regular ISO but a ready cloud image of the distribution in qcow2 format — it already contains the cloud-init agent and does not require manual installation through an installer.

wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
qm create 9000 --name ubuntu-24-04-template --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0

The number 9000 is arbitrary: it is convenient to reserve the range 9000-9999 for template IDs so they are not confused with production VMs. It is worth giving the name a clear meaning right away, for example including the distribution version.

How to Turn a VM Into a Template in Proxmox VE

After creating the VM, the downloaded disk is imported into it and a separate cloud-init device is attached, which stores the first-boot parameters.

qm importdisk 9000 noble-server-cloudimg-amd64.img local-zfs
qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-zfs:vm-9000-disk-0
qm set 9000 --ide2 local-zfs:cloudinit
qm set 9000 --boot c --bootdisk scsi0
qm set 9000 --serial0 socket --vga serial0
qm template 9000

The last command, qm template 9000, turns a regular VM into a template: the disk switches to read-only mode, and the VM itself disappears from the list of machines that can be started — from now on it serves as the source for clones.

Cloud-Init Settings: User, SSH Key, Network

First-boot parameters are set on the VM card's Cloud-Init tab or through the CLI, before the VM is turned into a template.

ParameterPurpose
Userthe account name that will be created on the system
SSH public keythe public key for passwordless login
IP Configa static IP or DHCP for the network interface
DNS domain/serversthe search domain and DNS server addresses

If the user and key are set at the template level, every clone gets the same starting data, while the specific IP address is more convenient to override after cloning — for that particular server.

Cloning a VM From a Template: Linked and Full Clones

A template can produce two types of clones: a linked clone and a full clone. A linked clone stores only the difference from the template's disk and is created almost instantly, but it depends on the source template and needs storage that supports this mode. A full clone copies the entire disk and no longer depends on the template after creation.

qm clone 9000 201 --name web-01 --full

More about the difference between snapshots and clones, and when a linked clone is riskier than a full one, is covered in the article on VM snapshots and cloning.

Automating Mass Deployment via the API

It is convenient to script cloning and cloud-init setup when servers are deployed regularly: the IP, name, and key parameters can be passed in right after cloning with one command.

qm clone 9000 202 --name web-02 --full
qm set 202 --ipconfig0 ip=10.0.0.22/24,gw=10.0.0.1
qm set 202 --sshkeys ~/.ssh/deploy_key.pub
qm start 202

The same result is achieved through the REST API without a node console — this is convenient for CI/CD and external orchestration systems. Details on calls and token-based authorization are covered in the article on the Proxmox VE REST API and automation.

Checklist Before Using a Template in Production

  • The image is based on an official cloud distribution with cloud-init support.
  • Template IDs are set apart in their own range and do not overlap with production VMs.
  • The SSH key in the template points to an account that outsiders cannot access.
  • The clone type is chosen deliberately: linked for speed, full for independence from the template.
  • The cloning and network setup process is tested on a staging server before a mass rollout.

Once verified, the template can safely be used for repeatable deployment of servers with the same configuration, without manually installing the OS on every machine.

← Back to Knowledge Base Ask Support