Why We Forked packer-plugin-proxmox

Every VM we run starts as a Packer build. Boot an ISO or clone a base image, run provisioners, freeze it as a Proxmox template. That template is the base for every Kubernetes node, database server, and edge VM we deploy. Reproducibility matters here: the same Packer config should produce the same template on Monday and on Friday, in June and in December.

The Hashicorp Packer plugin for Proxmox has not seen active development for a while. We forked it.

The fork lives at github.com/natrontech/packer-plugin-proxmox. It is a drop-in replacement for the Hashicorp upstream plugin. Switching is a one-line change.

Why we use Packer with Proxmox

We covered how Proxmox powers our infrastructure in a previous post. The short version: all our hypervisors run Proxmox VE, and we build every VM template with Packer. Packer lets us define templates as code, version them in Git, and build them in CI. No manual clicking through the Proxmox UI to configure a base image.

For this to be useful, builds have to be reproducible. A template is a starting point that we clone hundreds of times. If two builds from the same config produce different templates, we cannot reason about what is actually running in our infrastructure.

The upstream problem

The upstream plugin — hashicorp/packer-plugin-proxmox — works well for basic use cases. But issues are poorly addressed. Pull requests fixing real operational problems sat open for months without review.

We forked from upstream v1.2.3 and have been running our fork since.

What we changed

Controlling cloud-init package upgrades (Proxmox 8)

This is the change that triggered the fork.

In Proxmox 7, cloud-init did not run apt upgrade on first boot by default. In Proxmox 8, the default flipped: ciupgrade is now enabled, and cloud-init runs a full package upgrade the first time a VM boots.

For regular VM deployments, automatic package upgrades on first boot are often fine. For Packer template builds, they are not. When ciupgrade is on, every Packer run pulls in whatever package updates are available that day. A template built in week 23 contains different packages than one built in week 24. The config is identical; the output is not.

The upstream plugin had no way to control this. We added cloud_init_upgrade_packages:

source "proxmox-iso" "ubuntu" {
  # ...
  cloud_init                  = true
  cloud_init_upgrade_packages = false
}

Set it to false to disable upgrades and get a consistent template every time. Set it to true to force upgrades explicitly.

Skipping disk replication during builds

Proxmox supports storage replication: disks can be replicated across cluster nodes for redundancy. The upstream plugin had no way to disable replication on individual disks. We added skip_replication:

disks {
  type             = "scsi"
  disk_size        = "50G"
  storage_pool     = "local-lvm"
  skip_replication = true
}

Read-only disks

Some templates include a data volume that should not be writable after the build. We added read_only:

disks {
  type         = "scsi"
  disk_size    = "10G"
  storage_pool = "local-lvm"
  read_only    = true
}

Supported for scsi and virtio disk types. The plugin validates this at build time and rejects the config if you try to set read_only on a disk type that does not support it.

Bug fixes

We also fixed several bugs that caused silent incorrect behavior, including nameserver parsing errors being swallowed and a broken error message in network_adapters.

Switching to the fork

Replace hashicorp/proxmox with natrontech/proxmox in your Packer required_plugins block:

packer {
  required_plugins {
    proxmox = {
      version = ">= 1.3.0"
      source  = "github.com/natrontech/proxmox"
    }
  }
}

Run packer init to install the new binary. Every existing config option continues to work. The new options — cloud_init_upgrade_packages, skip_replication, read_only — are all optional with sensible defaults, so existing configs do not need to change unless you want to use the new features.

Releases are published to GitHub.

If you want to learn more about Proxmox, our Proxmox Migration Guide whitepaper covers planning and operations in detail.

What's next

We track upstream and will keep the fork in sync if the upstream project becomes active again.

If you are running Packer on Proxmox and want to benefit from newer features and bugfixes, switching takes one line. Existing configs continue to work unchanged. The fork is open source and contributions are welcome.