VELORA
GitHub Download

Zyvor · a platform for your Mac

New in 0.4 Console & Command, FluxVM clones, Kairon, fleet cards, a .pkg installer →

VMs, models and clusters.

One native Mac app: boot Debian, Ubuntu or macOS in one click, serve MLX models on your GPU, run Kubernetes, drive FluxVM and make the Mac a Kairon node. One memory ledger keeps it all honest.

Download 0.4.0 (.pkg).dmgSee it running

Pre-release · Apple silicon, macOS 26 or newer · 3 MB

Velora 0.4: VMs, models and clusters on your Mac, with a running Debian 13 machine, the Fleet screen and Console & Command

New in 0.4

A way into every guest, deeper FluxVM wiring, Kubernetes Nodes on your Mac, a live card for each Mac in the fleet and a standard installer.

What's new in 0.4: Console & Command, FluxVM clones and snapshots, Kairon, fleet cards, EXO across Macs (experimental), .pkg and DMG.
Console & Command running uname, os-release, uptime and df in a Debian 13 guest over vsock
Console & Command: real output from a Debian 13 guest, via vsock.
Fleet: a card for this Mac with memory, heat, disk, Thunderbolt and RDMA
Fleet: a card per Mac, refreshed every 5 seconds.
FluxVM: VMs, images, snapshots and clones
FluxVM: named images, snapshots and clones.
Kairon: this Mac as a Kubernetes Node
Kairon: this Mac as a Kubernetes Node.
Run commands in the guest with no network: Velora.app talks to velora-agent over virtio-vsock port 1024, with SSH as the fallback.
The Velora 0.4.0 installer package, Introduction step

A real installer

Releases now ship Velora-0.4.0.pkg next to the DMG: open it, click through, and Velora is in Applications. Both are built by CI on every tag, with a .sha256 beside each.

Download the .pkg

InstantNo installer. Cloud images with a login ready.
NativeSwiftUI, system materials and accent, light and dark.
Local-firstRuns as you. No account, nothing uploaded.
HonestIt says what is tested and what is not.

From pick to a shell in under a minute

After the image is downloaded, a Debian guest answered on SSH 23 seconds after launch on an M4 (measured, image cached).

Pick, download, prepare, boot, connect.

Debian 13 and Ubuntu 26.04 LTS

ARM64 cloud images with a cloud-init seed: user velora, your SSH keys installed, sudo without a prompt.

macOS

Asks Apple for the newest restore image your Mac supports, downloads it (about 17 GB), installs and boots it.

Drag and drop

Drop an .ipsw or .iso on the window to create and start a machine from your own file.

Resumable downloads

Images are cached, resumable and checksum-verified, so a retry never starts over.

The address, shown

The guest reports its own address, so Velora shows ssh velora@… right under the display.

No root, no extensions

Runs as your user on Virtualization.framework with NAT networking.

One run, time-lapsed

Velora: new machine, the image is prepared, the guest boots, the ssh address appears
New Machine, image prepared, boot, and the address appears. Twelve seconds of a real run.

More than VMs: models, clusters, FluxVM and Kairon

The same app serves MLX models on your GPU, runs k3s in Velora VMs and links to FluxVM and Kairon, all against one memory ledger.

Virtual machines, models, endpoints, training, Kubernetes, containers, fleet and FluxVM in one app sharing one memory pool.

Private OpenAI endpoints

Versioned, keyed, rate-limited, streaming, with health restarts and one-press rollback. Nothing leaves your Mac.

LoRA fine-tuning

Checkpoint, pause, resume and yield to inference, then serve the adapter as a new version.

One memory ledger

VMs, models, training and FluxVM VMs reserve memory first. Admission and concurrency, not GPU cores.

A client calls the gateway with a key, which proxies to an MLX worker on the GPU. Requests from VMs, models, training and FluxVM are admitted, queued or denied by one ledger.

Real runs, time-lapsed

Each clip is the app doing the work on an Apple M4: nothing is mocked.

Deploying an MLX model as an endpoint
Serve a model (already downloaded, so it is quick).
A LoRA training job from iteration 0 to 400
A LoRA job, iteration 0 to 400.
A k3s cluster going from creating to Ready
A k3s cluster comes up.
Kairon starts, this Mac becomes a Ready Node and a Machine boots
Kairon: the Mac becomes a Node and boots a Machine.
The FluxVM daemon starts and boots a VM
FluxVM boots a VM on the vz backend.

Kubernetes in one click

Velora boots Ubuntu 26.04 VMs, installs k3s, fetches the kubeconfig and waits for Ready. Verified for a single node on an M4; multi-node join is not verified.

New Cluster, server VM, node Ready, kubectl.

Your Mac as a Kubernetes node

FluxVM's new vz backend and Kairon's Mac node run natively. Velora hosts the cluster, supervises FluxVM and counts its VMs.

Kairon schedules a Machine onto the Mac node, FluxVM boots it on Virtualization.framework. Several Macs share models and place jobs by free memory over pinned TLS.

Mac tutorials

Step by step, each ending with exactly what was verified and where.

How it all works

Your GPU, stated honestly

GuestHostWhat it gets
macOSApple siliconAccelerated Metal paravirtual graphics on the host GPU.
LinuxApple silicon2D only Virtio display. Apple offers no 3D acceleration to Linux guests.
AnyAnyNot available GPU passthrough: impossible on Apple silicon, future work on Linux.

Runs on every Mac, from a Mac mini to a Mac Studio cluster

Unified memory is GPU memory. A Mac mini becomes a private assistant for the house; a few Mac Studios become an on-premise LLM endpoint that stays OpenAI-compatible and never sends data out.

Mac mini for home, Mac Studio for a team, MacBook Pro for development, all running Velora, FluxVM and Kairon.

Home, low cost

One Mac mini: a private chat endpoint with API keys, plus a Debian or Ubuntu VM. Silent, always on.

Small team

One Mac Studio: larger models, LoRA fine-tuning that yields to inference, k3s for the rest.

Regulated, on-premise

Two to four Mac Studios on a Thunderbolt 5 mesh for finance, legal, healthcare and air-gapped sites.

Clients call the Velora gateway, which serves models from a cluster of Mac Studios joined by Thunderbolt 5. Which model fits which Mac, from 16 GB to about 1 TB pooled. A Mac Studio cluster compared with a GPU server on memory, cost, power and operations.

Verified on one Apple M4 with macOS 27.2. Multi-Mac clusters and cross-node model sharding are on the roadmap; cost and power figures are from GK Servis's Mac Studio inference cluster case study. See Mac Studio, Mac mini and MacBook Pro on apple.com.

A native app, Apple's hypervisor, your VM

The SwiftUI app runs the guest itself on Virtualization.framework, in-process, with no helper service.

Velora.app drives Virtualization.framework, which boots Debian, Ubuntu or macOS. What each kind of guest gets from the GPU.

Download

Velora 0.4.0 (pre-release) for Apple silicon, macOS 26 or newer. Pick the installer or the disk image.

Velora-0.4.0.pkgVelora-0.4.0.dmgAll releases

FileSizeSHA-256
Velora-0.4.0.pkg2.9 MB773bb434ec8bcfa1ccd1a104fa0fd5c5dd748195748ea6d52e874951051a05d7
Velora-0.4.0.dmg3.5 MB7a558bcf1dfe89e63475dbe3e89b28d11c74083b0c4eb03b662f667076e4572f

Not notarized yet, so the first launch needs one override: right-click Velora (or the .pkg), choose Open, then Open. Or run:

xattr -dr com.apple.quarantine /Applications/Velora.app

Full guide: INSTALL.md.

Install

An Apple silicon Mac on macOS 26 or newer. Open the .pkg (or drag Velora from the DMG to Applications), then right-click Velora and choose Open the first time (the app is ad-hoc signed, not notarized).

Download the .pkgDownload the DMG

Press ⌘N, choose Debian, Ubuntu or macOS, then Create & Start. Then connect:

ssh velora@192.168.64.x        # the address is shown under the display; password: velora

Change the default password or rely on your SSH key before exposing a guest beyond your own Mac. See the install guide.