Managing a multi-node Proxmox cluster with Terraform sounded like a good idea. I searched for the most supported, up-to-date Terraform provider for it, bpg/proxmox, and got to work. Then my plan didn't apply and I got an SSH error??
The bpg/proxmox provider has wide resource support, expressive VM declarations, and solid handling of the cloud-config files I use to provision servers. But the big issue that wasn't immediately obvious is that it doesn't support snippets through the Proxmox API; it transfers them over SSH instead.
The SSH requirement
Cloud-init user-data and network-config files in Proxmox are stored as snippets. The Terraform provider needs to upload these to ${STORAGE_PATH}/snippets/ on the Proxmox host. But there's no API endpoint for that — just SSH file copy.
So now you need:
- SSH access to every node in your cluster: in my case fully separate accounts, as I log in to Proxmox using SSO
- SSH key-based auth configured: easy enough locally where I have an SSH agent attached to my password manager, but a bit of a pain for the GitOps pipeline
sudopermissions configured per-node: otherwise you get full root, which my sysadmin wasn't at all happy with
Convincing the cluster admin
In an enterprise cluster, each of these items is its own bureaucratic process:
- SSH access means adding your keys to
authorized_keyson every node. That's not automated, and your security team will ask questions when you submit the request. Key rotation means touching every node again. sudopermissions require a custom/etc/sudoers.d/entry with NOPASSWD for the copy operation. This is detailed in the provider documentation, but it still took a couple of tries to get right on the first node. And if the set of commands needed for snippet creation ever changes, you're touching the sudoers config again. I also had to justify each command individually — some of them Proxmox tools I wasn't fully familiar with — so I wasn't confident about the blast radius if something went wrong.
What really bugged me is that cloud-init should be a solved problem in 2026. Cloud images support it natively, which means I can write a Terraform module that always pulls fresh images and applies my config. It should be simple. Instead I was opening tickets with IT. I've used other hypervisors and never hit a wall like this with cloud-init. Even AWS, which structures its Terraform resources as weirdly as possible, supports this without batting an eye.
Plan for it
If you're evaluating Proxmox for Terraform in an enterprise setting, factor in the SSH overhead upfront. Key rotation, new cluster nodes, and any future change to the provider's snippet commands all mean going back to your cluster admin and security team.