Honest answers about kcore — what it is, what it isn't, and where it's going.
kcore is a virtualization platform — a modern alternative to Proxmox. It lets you manage VMs on bare metal servers using an API-first, declarative approach. The host OS is NixOS (immutable), the control plane is written in Go, and the API is gRPC.
No. kcore is alpha software. It is under active development and APIs may change without notice. It is suitable for experimentation, home labs, and early design partners. Do not use it for production workloads or business-critical infrastructure.
Proxmox is a mature, battle-tested platform with a large community. kcore is not trying to replicate Proxmox feature-for-feature. Instead, it takes a different architectural approach: API-first (not UI-first), declarative configuration, immutable host OS, and first-class support for automation agents.
Proxmox is the right choice if you need production stability today. kcore is for operators who want a cleaner, more programmable foundation and are willing to test alpha software.
kcore is built by Tacconi Consulting Ltd, a platform engineering consultancy based in England. We build and operate infrastructure for a living — kcore comes from real experience with the limitations of existing virtualization platforms.
Alpha means: core functionality works but is incomplete. APIs and configuration formats may change between releases. There is no stability guarantee. Things may break. We fix things quickly, but you should expect rough edges.
We don't set arbitrary deadlines. Beta means: the Terraform provider works, networking is solid, the API is stable enough to build on, and there's a web dashboard for visibility. Check the roadmap for current progress.
Yes, with caveats. If you are comfortable with alpha software, know your way around NixOS, and don't mind things changing — kcore works for home lab experimentation. Build the ISO, boot from USB, install to disk, and start creating VMs.
If you need something stable for important workloads, use Proxmox for now and keep an eye on kcore.
Not yet. There is no automated migration path from Proxmox to kcore. kcore is alpha software and not a drop-in replacement. When kcore reaches a more mature state, we plan to document migration strategies for common Proxmox setups.
Yes. kcore installs on separate hardware. You can run a kcore node on a spare machine or dedicated test server while keeping your Proxmox cluster running. They don't interact with each other.
If you're looking for a VMware exit path today, Proxmox is the pragmatic choice — it's mature and production-ready. kcore is a longer-term option for operators who want a more modern, programmable foundation. We'd rather you use the right tool now than adopt something that isn't ready.
Any x86_64 machine with hardware virtualization support (Intel VT-x or AMD-V). At minimum: 4GB RAM, 1 NIC, 1 disk. For useful VM workloads, 16GB+ RAM and SSD storage is recommended.
NixOS gives us properties that matter for a hypervisor host: immutable system state, atomic updates, instant rollback, and reproducible builds. Every node built from the same flake is identical. There is no configuration drift. A bad update is a reboot away from being undone.
Debian and Ubuntu are mutable — packages update in place, config files drift, and rollback is manual. Proxmox inherits these properties from Debian. We chose differently.
gRPC with Protocol Buffers gives us typed schemas, code generation, streaming, and efficient binary serialization. It's better for machine-to-machine communication — which is what matters when your API is the primary interface, not a web UI backend.
Clients can be generated in Go, Python, Rust, TypeScript, and other languages directly from the proto definitions. Agents get structured data, not JSON blobs to parse.
It means the platform is designed so automation agents — including AI agents — can interact with it through the same APIs humans use. There is no GUI-only workflow. The API has structured, typed inputs and outputs. The MCP server (in development) lets AI agents discover and use kcore operations through a standard protocol.
This is not "AI-powered infrastructure" marketing. It's a design principle: if software can't control it programmatically, it's a usability bug.
Licensing details will be published as the project approaches beta. The intent is to keep kcore usable for individuals, home labs, and small operators without restrictive licensing. Contact us at team@tacconiconsulting.com if you have specific licensing questions.
The business model is not finalised. If there is a paid tier, it will be for commercial support, enterprise features, or managed services — not for gating core functionality. We'll be transparent about this as the project matures.
Reach out. We're happy to answer questions about kcore, its architecture, or where it's headed.