If you already run Proxmox, this is the natural place to put deputyOS. It ships as a community template wrapping the qemu-x86_64 build, so it behaves like any other guest.

Creating the VM

Download the qcow2 from the picker with proxmox selected, then on the Proxmox host:

qm create 900 --name deputyos --memory 8192 --cores 4 --net0 virtio,bridge=vmbr0
qm importdisk 900 deputyos-x86_64-standard.qcow2 local-lvm
qm set 900 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-900-disk-0
qm set 900 --boot order=scsi0
qm set 900 --cpu host
qm start 900

--cpu host matters: without it the guest may not see virtualisation features and local inference gets much slower.

Finding the wizard

Check the guest’s address from the Proxmox console or your DHCP table, then open http://<ip>. mDNS usually works if the guest is bridged onto your LAN, so http://deputyos.local is worth trying first.

Snapshots and backups

Proxmox snapshots work normally and are the fastest safety net before an upgrade.

Worth understanding: deputyOS also does its own A/B slot updates with watchdog rollback. The two are complementary — A/B handles a bad update automatically, Proxmox snapshots handle everything else, including your own mistakes.

GPU passthrough

If the host has a spare GPU, passing it through transforms local inference. Requires IOMMU enabled in firmware, the GPU in its own IOMMU group, and the host not using the card. Proxmox documents this well.

Why bother, given Proxmox already manages VMs

Proxmox manages hypervisors and guests. It will tell you the VM is running; it will not tell you whether the assistant inside is healthy, which model it is calling, or what it spent yesterday. That is the layer deputyOS adds — see deputyOS vs Proxmox.