Best approach for managing Proxmox VPS templates with Cloud-Init?

ceonguyen

New Member
Sep 4, 2026
1
0
1
'm planning to build a VPS hosting service using Proxmox VE.

I want to maintain a small number of clean OS templates, for example Ubuntu 22.04, Ubuntu 24.04, Debian, etc. When a customer orders a VPS, my application will clone the appropriate template and configure the new VM automatically.

One requirement is that customers should be able to log in directly as root via SSH using a randomly generated password.

I'm wondering what would be the best architecture/method for this.

Should I:

  • Prepare the template with root SSH/password login already enabled?
  • Keep the template completely clean and use Cloud-Init to configure root login/password for every new VM?
  • Generate a custom Cloud-Init configuration for each VPS?
  • Use another Proxmox/Cloud-Init mechanism that is more appropriate for a VPS hosting environment?
I'm mainly interested in the recommended approach and best practices for a VPS provider, especially regarding template management, Cloud-Init, root access, SSH host keys, and cloning.

The goal is to avoid maintaining many different templates and have the provisioning process fully automated from my application.
 
I can't answer all your questions, but I might be able to fill in some of the gaps...

I've written a simple HOWTO on this topic here:

My post is in German, but with today's translation tools, that shouldn't be a problem.

Prepare the template with root SSH/password login already enabled?
I wouldn't want to set a password for root at all. If there is a root login, it should be key-based only.

Keep the template completely clean and use Cloud-Init to configure root login/password for every new VM?
I would at least provide recommended software and configuration settings as a default for the customer's convenience. I would document this default setting on the page where users select their VPS. It's fine to include a few fancy extras too.. like Fortune, for example ;)

Otherwise, I would have the system create a username and password selected by the customer during the build (of course, there is a password policy in place). As a general rule: As soon as the customer has root access to their VPS, they can do whatever they want anyway. Therefore, it’s also important to isolate each VPS in its own network and/or use the Proxmox Firewall+SDN.

Generate a custom Cloud-Init configuration for each VPS?
If necessary...
 
  • Like
Reactions: Johannes S
Adding to fireons comment I would like to add this: At my place of work I spent the last three weeks creating new vm templates (although we are running vmware but cloud-init isn't that different there). Since I needed to fullfill some special requirements my final cloud-config ended in quite a complex mess of used modules, #include files and corner cases. Debugging before I finally managed to get them to work them wasn't fun since cloud-inits tooling for trouble shooting is quite limited (imho that's not so much the fault of cloud-init but just comes with the terrain: After all we are doing stuff during boot before network etc is configured). So if you havn't any good reason to do otherwise I would use cloud-init just for the minimal provisioning (hostname, network-config (DHCP,SLAAC would be my recommendation), login and sudo credentials (ssh keys preffered)) and do everything else with a configuration managment software like ansible, salt, chef or puppet. The ansible module of cloud-init even allows to run ansible-pull against a git repo containing a playbook for doing everything else after the initial provisioning.
On the other hand this advanced features (including the ansible module) can't be used from ProxmoxVEs webui anyhow, so maybe that's not that much of an issue for you. You can still use them with PVE though but then you need to use the qm cli tool to set it: https://pve.proxmox.com/wiki/Cloud-Init_Support#_custom_cloud_init_configuration

And even with ProxmoxVE webui you could just do something like setting the username to "ansible" (or puppet or chef) and a public ssh key for you control nodes technical user and afterwards let the config managment tool do it's thing.
tldnr: Use cloud-init for the initial, minimal provisioning of the network config and initial user credentials, for everything else use the config managment tool of your choice (ansible, puppet/openvox, salt, chef, whatever)
 
Last edited:
  • Like
Reactions: UdoB and fireon