← Back to blog

I like Proxmox. I've run it in home labs and small production setups for years. It does what it says: you get a web UI, you create VMs, it works. But every time I tried to automate it properly, I hit walls.

The API is an afterthought

Proxmox has a REST API, but it's a thin wrapper over the web UI. It wasn't designed as a first-class interface. Half the time you end up shelling out to qm or pvesh from Terraform or Ansible because the API doesn't expose what you need. That's not automation, that's scripting around a GUI.

When your Terraform provider has to SSH into the host and run CLI commands to get things done, something is wrong with the API.

The codebase is from another era

Proxmox is built on Perl. The management framework (pve-manager), the API server, the cluster stack with Corosync and the custom filesystem (pmxcfs) — it all comes from a time when Perl was a reasonable choice. Try debugging a cluster split-brain through layers of Perl and Corosync. It's not fun.

Upgrades are scary

Proxmox runs on Debian. Upgrading means doing an in-place upgrade on a mutable system that's running your production VMs. There's no atomic rollback. If something goes wrong, you're restoring from backups.

In practice, most people just don't upgrade. I've seen Proxmox clusters running versions years out of date because nobody wants to risk it.

What kcore does differently

kcore runs on NixOS. The configuration is declarative — every node is built from the same definition, so there's no drift. When you update, NixOS creates a new system generation. If it breaks, you roll back to the previous one. That's it.

The API is the primary interface, not a bolt-on. It's gRPC with typed schemas, not a REST wrapper over a web UI. The control plane is written in Go. VMs are defined in YAML and applied declaratively, same as you'd manage Kubernetes resources. 

apiVersion: kcore.io/v1
kind: VirtualMachine
metadata:
  name: web-01
spec:
  cpu: 4
  memory: 8G
  disk: 100G
  network: default

You apply it, the controller figures out which node to put it on, the node agent talks to libvirt, and the VM comes up. No clicking through a web UI, no copy-pasting shell commands.

What kcore doesn't do (yet)

kcore is alpha. There's a lot it doesn't have that Proxmox does:

If you need those things today, use Proxmox. It's battle-tested and it works.

But if you're tired of fighting Proxmox's API, you want declarative infrastructure, and you're comfortable with alpha software, take a look at kcore. The goal is a hypervisor that works the way modern infrastructure tools work: API-first, declarative, reproducible.