Machina
Your metal. Your cloud. One control plane.
The private cloud you can install before lunch. VMs, browser consoles, fleet HA/DRS, an OpenStack-style self-service cloud, a native eBPF datapath and AI operations, from a handful of Rust services on plain Linux + KVM.
One-command install · SQLite built in, PostgreSQL when you grow · EC2-compatible API · A way off OpenStack · Consoles built in · eBPF networking built in · AI that asks before it acts
What's new
Bare-metal provisioning. Discover or import BMCs, commission machines over PXE or BMC virtual media, write a
checksum-verified OS image and let each machine join the fleet on first boot, driven from machinactl metal … or the
Bare Metal page. Verified on VMs and BMC emulators, not yet on physical servers; see the
guide and claims C49 to C51.
EC2-style Fleet Cloud. Launch several instances at once with a key pair and first-boot user data, tag everything,
firewall with enforced security groups whose status tells the truth, attach volumes with live I/O limits, scale groups from
alarms, give a team a project-scoped API key, and drive it all from awscli or boto3 against the built-in EC2-compatible endpoint.
Start with the tutorials; every feature has a guide, and
what is proven on a real host and what is not is written down.
VPC foundations and elastic compute are available as a first host-local backend.
See the operator guide for isolation, deployment,
CPU scaling, and the explicit routing/peering limitations.
| |
|---|
| Scale to zero | Idle VMs sleep (memory saved to disk, RAM handed back to the host) and wake on the first packet sent to them. How → |
| Time travel | Fork a running VM in seconds, with or without its RAM; scheduled restore points and one-click rewind. How → |
| Stacks you describe | Say what you want in a sentence; get a template, a dry run (quota, placement, cost, policy replay), an approval, then a stack that heals its own drift. How → |
| Autopilot capacity | Instance groups scale ahead of the daily or weekly rush, drain from their load balancer, and sleep instead of stopping; VMs are right-sized from their own history and hosts consolidated, each through an approval you can undo. How → |
| Game days | Inject latency, loss, partitions, slow disks and crashes into your own VMs under a lease; health probes abort the run and lift every fault when the service suffers; a report per step. How → |
| Preemptible instances | VMs that can wait give way when a host runs short of memory: saved to disk instead of stopped, back by themselves, lowest priority first, when there is room. How → |
| Boot Doctor | A VM that won't boot gets diagnosed and repaired offline through GuestKit, with a backup taken first. |
| VM quarantine | Isolate a suspect VM in the eBPF datapath under a time-boxed lease that lapses on its own. |
Why Machina
| When this happens… | Machina gives you… |
|---|
| You want a private cloud, but OpenStack is a six-week project and a full-time team | ./machinactl deploy: a few Rust services, embedded SQLite (PostgreSQL when you outgrow it), a browser UI on :5092 minutes later |
| VMware renewal quotes keep climbing | Open KVM/libvirt underneath, with HA failover, DRS and live migration on top |
libvirt ops live in a pile of virsh scripts | One dashboard, a REST API with 1,000+ routes, a CLI and a Terraform provider over the same model |
| Every console needs its own gateway | noVNC, SPICE, serial and SSH proxied by the daemon, with RBAC and audit |
| Networking means Cilium + Tetragon + kube-proxy + a firewall agent | One eBPF service, machina-bpfd: load balancing, DDoS shield, VM isolation, flow visibility |
| On-call means triaging the same incidents at 3 a.m. | Zyra AI diagnoses, correlates and proposes the fix, then waits for a human approval |
Evaluating? Why Machina (five minutes) · Alternatives · Security and compliance · 30-day evaluation plan. Using it? Tutorials · Cookbook.
Replace OpenStack
Machina covers the private-cloud primitives most OpenStack deployments use: identity, compute, networking, images, volumes,
orchestration, load balancing, a dashboard, HA and alarms. It is not a drop-in: there is no Nova or Neutron API, so tools
move to Machina's REST API or its EC2-compatible API, and guests move as disk images.
| OpenStack | Machina |
|---|
| Keystone | PAM, OIDC, SAML, LDAP, RBAC, project-scoped API keys |
| Nova, Placement | machina-daemon and machina-agent on libvirt/KVM; the controller schedules, with live migration, HA and DRS |
| Neutron | Native eBPF VM edge and network policy, VPC objects, NAT, Elastic IPs, WireGuard overlay between hosts |
| Glance | Images and templates, Golden Forge builds |
| Cinder | Volumes with I/O limits and snapshots; Atlas for Ceph, NFS or ZFS |
| Heat | Stacks with dry run, approval and drift repair |
| Octavia | Native layer-4 balancer on the host, no amphora VM |
| Horizon | The web UI, with browser consoles |
| Masakari, Watcher | HA failover and DRS in the controller |
| Ceilometer, Aodh | Metrics history, alarms with scaling actions, Prometheus and OTLP |
| MariaDB, RabbitMQ | SQLite or PostgreSQL; in-memory task bus, NATS optional |
Gaps, stated plainly: thousands of tenants and Neutron-grade SDN breadth are out of scope; the OpenStack client tools and
ecosystem projects do not work against Machina; there is no OpenStack importer, and moving a guest as a disk image has not been run end to end on a real OpenStack
cloud. Which features have run on a real host and which are unit-tested only: claims.md. The full map, with how to move a workload: Replacing OpenStack.
Machina vs OpenStack, side by side
| Machina | OpenStack (typical IaaS) |
|---|
| Services to run | 4 Rust services | 9+ services (Keystone, Nova, Neutron, Glance, Cinder, Placement, Horizon, Heat, Octavia) |
| Backing infrastructure | Embedded SQLite or PostgreSQL; optional NATS | MariaDB/Galera, RabbitMQ, Memcached |
| Install | ./machinactl deploy | Kolla-Ansible / OpenStack-Ansible project |
| Smallest useful footprint | A single KVM host | A multi-node control plane |
| Flavors, images, volumes, SGs, stacks, LBs | Yes, in Fleet Cloud | Yes, across six projects |
| Load balancer data plane | On the host, no amphora VM: iptables rules for Fleet Cloud, eBPF Maglev for Kubernetes services | Amphora VMs (Octavia) |
| Network datapath | Native eBPF, lease-gated enforcement | Neutron agents + OVS/OVN |
| Browser consoles | Built into the daemon | noVNC/SPICE proxy services |
| HA failover and DRS | Built in (controller HA) | Masakari + Watcher (separate projects) |
| AI operations | Zyra AI, approval-gated | Not included |
| Idle VMs | Scale to zero: sleep when idle, wake on the first packet | Shelve and unshelve by hand |
| Copies and rollback | Time travel: live fork (optionally with RAM), restore points, rewind in place | Snapshot uploads a full image to Glance; rebuild from it |
| Orchestration | Stacks drafted from a description, dry-run with cost and policy replay, approved, then kept in sync every minute |
Machina targets the fleets you own: a lab, a branch, a sovereign region, a VMware exit. It deliberately trades OpenStack's hyperscale multi-tenancy for a cloud one person can install, understand and upgrade.
See it live
Captured from a real deployment on Ubuntu 26.04 in the dark theme, not mockups.
Every VM operation, in one place
Create, clone, snapshot, back up and migrate. Cloud-init, GPU and PCI passthrough, golden images built with Packer (Linux, plus Windows 10/11 through dockur when enabled), networks, storage pools and nwfilters. VM guide →
Consoles in the browser, no gateway to deploy
noVNC, SPICE, serial and SSH are proxied by machina-daemon itself, behind the same RBAC and audit log as everything else. VM detail leads with a live console preview. Console architecture →
A fleet, not a host
Add hypervisors with a gRPC agent over TLS. The controller keeps desired state, fails VMs over when a host dies, balances load with DRS and live-migrates between hosts. Controller HA and DRS →
Fleet Cloud: self-service like a public cloud
Flavors, images, instances, volumes and snapshots, security groups, keypairs, floating IPs, server groups, Heat-style stacks, projects and load balancers, all native controller APIs. Beyond that, idle instances can scale to zero and wake on traffic. EC2-style semantics on top: tags and ids, instance types, user data, enforced security groups, Elastic IPs and a NAT gateway, an instance metadata service, alarms with scaling actions, project-scoped API keys, and an EC2-compatible endpoint (aws/boto3 work with an endpoint override). EC2 semantics → · EC2 API → Fleet Cloud → · Features OpenStack doesn't have →
Zyra AI: an operator that asks first
Autonomous diagnostics across the fleet, incident correlation, rightsizing and natural-language operations, with bring-your-own LLM providers (keys encrypted at rest) and an approval queue in front of every change. Zyra AI →
Networking and security, in the kernel
Machina ships its own eBPF datapath instead of bolting on Cilium, Tetragon or a separate firewall agent. One root service, machina-bpfd, provides:
- Load balancing: Maglev service LB for Kubernetes (socket-level, NodePort at TC or XDP, DSR) and QUIC-LB at XDP.
- Kubernetes CNI (opt-in):
machina-cni replaces flannel and kube-proxy where you choose it, with NetworkPolicy and Cilium policy migration. It never takes over an existing CNI.
- VM network policy: which VM may talk to which, ingress and egress, written as CiliumNetworkPolicy YAML and enforced on each VM tap without Cilium or Envoy. This covers L3/L4, DNS names (
toFQDNs), L7 (HTTP, gRPC, Kafka, TLS SNI, DNS), TLS interception with header rewrites, CIDR groups and mutual authentication (mTLS between hosts). Comes with policy trace and Hubble-style flows in the UI and in machinactl netpol / machinactl flow, plus flow history (service map, learn, replay, L7 metrics), quarantine, just-in-time access, lateral-movement alerts, DNS threat feeds, plain-English policies, project isolation, egress allowlists and IPs (added to the host and announced by Machina), an encrypted WireGuard overlay that keeps VM identity across hosts, VM addresses found without a guest agent (neighbour tables and tap traffic), and segmentation evidence export.
- Protection: XDP DDoS shield, emergency node isolation, VM edge isolation and rate limits, a QEMU sandbox and a BPF-LSM guard around the VMM.
- Visibility: flows, DNS, L7 (HTTP, TLS SNI, gRPC, Redis, PostgreSQL, MySQL, Kafka), JA3/JA4 fingerprints, network-change audit and per-VM runtime histograms.
- Inside guests: per-container network and LSM policy through GuestKit, from the VM's Guest policy tab.
Everything that can drop traffic starts in observe mode and enforces only under a time-boxed lease that the kernel honours on its own; nothing is persisted. Native eBPF →
And the rest of the platform
- Identity and access: PAM, OIDC, SAML and LDAP sign-in, role-based access, a full audit trail. Admin guide →
- Containers: local Podman/Docker containers and Podman pods next to your VMs. Containers →
- Kubernetes: KubeVirt inventory and a documented migration path. KubeVirt →
- FluxVM: QEMU, Cloud Hypervisor, Firecracker and flux-vm VMs from FluxVM next to libvirt VMs, with snapshots, backups, hot-add, install ISOs, live migration and fleet HA. FluxVM →
- Observability: Prometheus metrics, OTLP export, PSI/cgroup pressure, alerts and webhooks. Observability →
- Storage: Atlas integration puts VM disks on Ceph RBD, NFS or ZFS volumes with snapshot, backup and restore. Atlas →
- Automation: Terraform provider, TypeScript SDK, OpenAPI spec,
machinactl.
How it fits together
| Component | Port | Role |
|---|
machina-daemon | :5092 | Single-host API, auth/RBAC, console proxies, web UI |
machina-controller | :5093 | Fleet, HA, DRS, Fleet Cloud, Zyra AI (SQLite or PostgreSQL) |
machina-agent | :50051, :50052 | Per-host gRPC agent (TLS) for libvirt and eBPF ops; :50052 is its console proxy |
machina-bpfd | unix socket | Root eBPF datapath, telemetry and enforcement (/api/v1/bpf/*) |
machina-cni | — | Opt-in Kubernetes CNI plugin and node agent |
machina-scx | — | Optional sched_ext VM scheduler (kernel 6.12+) |
The daemon alone is a complete single-host manager. Add the controller and an agent per host for a fleet; machina-bpfd runs on every host that should get the eBPF datapath.
Database: SQLite or PostgreSQL
The controller keeps its state in one database. Both backends come from one source tree and are chosen when the controller is built.
| SQLite (default) | PostgreSQL |
|---|
| Setup | None; one file, created and migrated on first start | machinactl db setup pod|package|external |
| Fits | 1 or 2 hosts, labs, evaluations | Hundreds of machines |
| Controllers | One | Several on different hosts; one leader, hand-over inside the lease |
| Way back | n/a | machinactl db setup sqlite (the SQLite file is never touched) |
sudo machinactl db setup pod --migrate # managed PostgreSQL 16 in Podman, copies your SQLite data
sudo machinactl db status # backend, login, size, migrations
sudo machinactl db backup # pg_dump, or an online copy on SQLite
# or at install time: scripts/install-platform.sh --database pod|package|external|sqlite
Every schema change ships as two migrations, and CI prepares every SQL statement against PostgreSQL. Status: the PostgreSQL build passes the controller's whole test suite on PostgreSQL 16, and an isolated PostgreSQL-backed controller was run live (two controllers on one database elect one leader and hand over within the lease; 500 machines list in under a second), and a copy of the lab host's real database loaded with identical row counts. Not done yet: a PostgreSQL controller managing real hosts. Until a site has run on it, SQLite stays the safe default (claim C24, guide).
EC2-compatible API
The controller answers four AWS query services (EC2, Auto Scaling, ELBv2 and CloudWatch-style alarms) with SigV4-signed requests, so
aws, boto3 and Terraform's aws provider work with an endpoint override. It is a compatibility layer over Machina's own objects, not AWS: 288 actions are
mapped, each one applied, recorded as a stored plan, or refused by name, never silently dropped. The per-action status table is generated from the code.
# an admin creates an access key through the daemon (the secret is shown once)
curl -sk -c jar -X POST https://HOST:5092/api/v1/auth/login -H 'content-type: application/json' -d '{"username":"USER","password":"PASS"}'
curl -sk -b jar -X POST https://HOST:5092/api/v1/platform/controller/api/v1/ec2/access-keys \
-H 'content-type: application/json' -d '{"description":"ci"}'
# the EC2 endpoint is plain http on the controller's loopback port 5093; run this on the host, or tunnel:
# ssh -N -L 15093:127.0.0.1:5093 USER@HOST (then use http://127.0.0.1:15093)
export AWS_ACCESS_KEY_ID=MCAK… AWS_SECRET_ACCESS_KEY=… AWS_DEFAULT_REGION=machina
EC2=http://127.0.0.1:5093/ec2
aws --endpoint-url $EC2 ec2 run-instances --image-id <ImageId> --count 3
aws --endpoint-url $EC2 ec2 describe-instances
import boto3 # same endpoint, same keys (run on the host or through the tunnel)
ec2 = boto3.client("ec2", endpoint_url="http://127.0.0.1:5093/ec2", region_name="machina")
print([i["InstanceId"] for r in ec2.describe_instances()["Reservations"] for i in r["Instances"]])
Status: implemented and unit-tested; not every action has been exercised with a stock client (what has been run). API and action table → · Clients and Terraform → · Semantics →
Quickstart
On any Linux host with KVM (Ubuntu, Debian, Fedora, RHEL/Alma/Rocky, openSUSE, Arch):
git clone https://github.com/zyvorai/zyvor-machina.git machina && cd machina
./machinactl deploy # deps · build · install · start · verify
# open https://<host>:5092 and sign in with a local (PAM) account
# controller state is embedded SQLite; for PostgreSQL see "Database" above
# (package installs create an admin user instead: sudo machinactl show-login prints it)
From your laptop to a remote host (sources are rsync'd and built on the server; nothing compiles locally):
./scripts/deploy-remote.sh user@host # build + install daemon and web UI on the server
./scripts/deploy-remote.sh user@host --platform # plus controller and agent
./scripts/deploy-remote.sh user@host --remote-build # compile only, no install (fast build check)
Requirements
- 64-bit Linux (x86_64 or aarch64) with VT-x/AMD-V, so
/dev/kvm exists, and libvirt. Release packages cover amd64 and arm64.
- Ubuntu, Debian, Fedora, RHEL/Alma/Rocky, openSUSE or Arch.
- Native eBPF: kernel with BTF and cgroup v2; 6.6+ for TCX attach, BPF-LSM (
lsm=...,bpf) for VMM guard enforcement, 6.12+ for the sched_ext scheduler. GET /api/v1/bpf/status shows what your kernel supports.
- Ports:
5092 (daemon, web UI), 5093 (controller), 50051/50052 (agent). Full port list →
- Any current browser; consoles need no plugins.
Maturity
| Area | Status |
|---|
| VMs, storage, networks, consoles, auth, audit | Stable |
| Fleet, HA with fencing, DRS, live migration | Stable |
| Fleet Cloud | Stable |
| eBPF observability | Preview |
| eBPF enforcement | Preview, lease-gated |
machina-cni | Preview, opt-in |
| QUIC-LB, AF_XDP, sched_ext, guest policy | Opt-in |
| Zyra AI | Stable, approval-gated |
| Atlas storage integration | Opt-in (ATLAS_ENABLED=1) |
Develop
The Rust workspace needs Linux libvirt headers; build on Linux (or use deploy-remote.sh --remote-build from a Mac). The web UI builds anywhere.
make build && make test && make lint # Rust workspace (Linux)
make bpf-deps # eBPF toolchain: nightly + bpf-linker
sudo make bpf-test # eBPF netns smoke (veths only)
cd web && npm install && npm run dev # UI on :3000, proxied to a daemon on :5092
cd web && npm test && npm run build # vitest + typecheck + bundle
Start with Engineering onboarding; architecture and conventions are in CLAUDE.md.
Part of the Zyvor stack
| Product | Role |
|---|
| Machina | Private cloud on KVM: VMs, fleet, Fleet Cloud, native eBPF, Zyra AI |
| Atlas | Storage control plane (Ceph/NFS/ZFS) for VM disks, snapshots, backups |
| GuestKit | In-guest agent, offline inspection, per-container eBPF policy |
| hyper2kvm | VM migration into KVM |
→ zyvor.dev
License
Machina is source-available under the Zyvor Production License v1.0 (SPDX LicenseRef-Zyvor-Production-1.0).
- Free for evaluation, development, testing, research, education, homelabs and all other non-production use.
- Production use requires an annual enterprise subscription. Plans, support levels and terms: SUBSCRIPTION-MODEL.md · licensing model.
Contributions are welcome under the same license; see CONTRIBUTING.md. Report vulnerabilities privately per SECURITY.md.
Ready to run your own cloud?
