Orka release notes

Release summary

New features

VM User Data

# From a script file (encoded automatically)
orka vm deploy --image my-golden-image --userdata ./bootstrap.sh

# From a base64 string
orka vm deploy --image my-golden-image --userdata "$(base64 -i bootstrap.sh)"

• The script runs as root, in the background, and never delays the VM becoming available. The VM is reachable while the script runs.
• It runs once per VM. Completion is recorded after the script finishes, whether it succeeded or failed, so a failed run does not retry on the next boot. A VM that reboots or stops mid-script has not completed, and re-runs the script on its next boot, so write scripts that are safe to re-run.
• A VM deployed from an image that was saved or pushed after its own User Data ran still runs its own script. The run-once record is tied to the deployment, not the image.
• There is no timeout by default. Set ORKA_USERDATA_TIMEOUT inside the image if you want one.
• Output is written to /var/log/orka/userdata.log inside the VM.
• The base64-encoded script can be up to 64 KiB. For anything larger, have a small User Data script download the real payload.

Android emulators are generally available

orka emulator deploy --vm my-macos-vm --platform android-36 --image-type google_apis

Android emulator gRPC endpoint

orka emulator deploy --vm my-macos-vm --platform android-36 --image-type google_apis --grpc

Android emulator configurations

# Create a configuration
orka emulator-config create android-36-google-apis --platform android-36 --image-type google_apis

# Deploy from it
orka emulator deploy --vm my-macos-vm --config android-36-google-apis

# Override one setting at deploy time
orka emulator deploy --vm my-macos-vm --config android-36-google-apis --device-profile pixel_tablet

• Configurations are created in the orka-default namespace and are available to every user and service account with access to it.
• Any of --platform, --image-type, and --device-profile override the configuration at deploy time. Pass an empty --device-profile "" to use the avdmanager default instead of the configuration’s profile.
• Settings are copied into the emulator when it’s deployed, so editing or deleting a configuration never affects emulators already running.
• Manage configurations with orka emulator-config create, list, and delete (alias orka emc), or the /api/v1/namespaces/{namespace}/emulatorconfigs/android API endpoints.

Manage role subjects with orka rbac

# Grant the admin role to a service account
orka rbac add-subject --role admin --serviceaccount orka-default:sa-jenkins

# Grant the dev role in one namespace to a user
orka rbac add-subject --role dev --namespace orka-test --user user@company.com

# See who has a role, and remove a subject
orka rbac list-subjects --role dev --namespace orka-test
orka rbac remove-subject --role dev --namespace orka-test --user user@company.com

Improvements

Control plane resilience

• PodDisruptionBudgets protect orka-webhooks and the HA control-plane components during node drains and maintenance. Orka creates the orka-webhooks budget on every cluster, so don’t add one of your own: two budgets selecting the same pods make Kubernetes refuse to evict them, and a node drain during a Kubernetes upgrade hangs. See Kubernetes upgrade guide.
• Kubelet resources are reserved on control-plane nodes.
• MacStadium-hosted clusters only: Orka components also run under dedicated PriorityClass tiers, with kube-vip set to system-node-critical, and get per-component resource requests and limits. On AWS and on-prem clusters, Orka creates no priority classes, because they are cluster-wide and could preempt your own workloads, and leaves resource requests and limits empty so you can size them for your environment.

Observability

• The operator reports a pending-VM queue-depth metric and adds a vm_namespace label to its metrics, giving you a leading indicator of VM deployment backlog before deploy times start to climb.
• The deploy-duration histograms now use exponential buckets, so observations land in finite buckets and percentiles are meaningful. Bucket series and VM lifetime metrics are now included in the Prometheus allowlist.
• orka-webhooks now exposes a metrics endpoint that Prometheus scrapes, and previously missing control-plane metrics have been added to the scrape allowlists.

Node scheduling

• Image-cache and push jobs have their own per-node budget, default 2, tunable with the osx_node_orka_quota_job Ansible variable. Jobs no longer compete with VMs or emulators for a slot.
• The node pod quota is raised to 110, the Kubernetes default. It no longer limits how many VMs, emulators, and jobs run together, since VMs and jobs each have their own limit.
• Emulators aren’t capped. They’re counted per node, so kubectl describe node shows how many are running.
• Emulators are placed by the Kubernetes scheduler on their paired VM’s node. If the scheduler can’t place one, for example because that node is cordoned, the emulator stays Pending with the scheduler’s reason in its error message. After 5 minutes it fails with EmulatorUnschedulable.

Deprecations

• CLI: orka image (list, copy, delete, set-description), orka remote-image (list, pull), orka vm save, and orka vm commit print a deprecation warning to stderr and are marked (Deprecated) in their help.
• API: the images and remoteimages routes and POST /vms/{vm}/save and /vms/{vm}/commit return a Deprecation: true header and a Warning header naming the OCI replacement, and are marked deprecated in the API reference.
• orka imagecache, the cache/images routes, and VM deploy aren’t affected, because they serve OCI images too.

Breaking changes

CLI renamed to orka

• Update every script, CI job, and integration that calls orka3 to call orka. Commands, flags, and output are otherwise unchanged, apart from the Intel removals listed below.
• Download the 4.0 CLI from Orka tools, CLI downloads, and CI/CD plugins. On macOS, installing the 4.0 package leaves the 3.x orka3 binary in place, so you can keep both installed.
• On macOS with Homebrew, install the 4.0 CLI with brew install --cask orka. The orka3 cask stays on 3.x, and brew upgrade doesn’t move you from orka3 to orka.
• The 3.x CLI stays orka3. If you manage clusters on both Orka 3.6 and 4.0, use orka3 for 3.6 clusters and orka for 4.0 clusters.
• orka and orka3 read the same config file and the same orka kubeconfig context. Switching between a 3.6 cluster and a 4.0 cluster still means running config set --api-url and logging in again, whichever CLI you run.

• macOS and Linux: sudo ln -sf "$(command -v orka)" /usr/local/bin/orka3
• Windows: copy orka.exe to orka3.exe in the same folder.

Intel removals

CLI

• Removed commands: orka3 vm start, vm stop, vm suspend, vm resume, vm revert, and orka3 image generate.
• Removed command groups: orka3 iso (list, copy, delete, set-description) and orka3 remote-iso (list, pull).
• Removed flags on vm deploy and vmc create: --iso, --gpu, --disable-net-boost, --legacy-io, and --system-serial.
• Removed flags on vm resize: --user and --password. Resize on Apple silicon works exactly as before.
• orka vm and orka image now reject unknown subcommands with a non-zero exit code. Previously, an unknown subcommand such as orka3 vm bogus printed help and exited 0. Without this change, a script still calling a removed command such as vm stop would have read it as success.

API

• POST /api/v1/namespaces/{namespace}/vms/{vm}/exec
• POST /api/v1/namespaces/{namespace}/images (image generate)
• POST /api/v1/namespaces/{namespace}/upload/image and GET/HEAD /api/v1/namespaces/{namespace}/images/{image}/download. Apple silicon images move through OCI push and pull.
• All /isos, /remoteisos, and POST /upload/iso routes

Kubernetes resources

Web UI

• The VM Start, Stop, Suspend, Resume, and Revert actions have been removed. To restart a stopped VM, redeploy it.
• The Generate Image action and the ISOs page have been removed.
• The GPU, net boost, and ISO fields and columns have been removed from VM and VM config views.
• The Enable VNC checkbox has been removed from the Deploy VM and Create VM Config dialogs. It only applied to Intel configs. VM configs created from the Web UI keep VNC enabled, and deploys use the VM config’s own VNC setting.

Bug fixes

• Fixed: After a node outage, the disk sweeper could delete the disk of a VM whose pod still claimed it. VM disks are now kept for as long as a pod references them.
• Fixed: Resizing a VM could hang for up to 5 minutes and fail with a bare DeadlineExceeded error, because the repartition request was sent before the guest tools were ready to receive it. Resize now waits for the guest tools and bounds each wait with a clear error.
• Fixed: A VM deployed moments after creating its VM config could be rejected with an admission error because the config wasn’t visible to the webhook yet.
• Fixed: orka imagecache remove --all and --tags returned 404 for nodes that didn’t have the image cached. These nodes are now skipped: the request returns 207 Multi-Status with a 202 for each node. A node you name with --nodes that doesn’t have the image cached still returns 404.
• Fixed: Orphaned Failed and RemoveFailed cache entries lingered in orka imagecache info output. They’re now cleaned up, and removing an image with no cache record reports that clearly.
• Fixed: When a pull or import was short on space, cache eviction freed the full required size rather than the shortfall, so it evicted several cached images instead of one. An operation the whole cache couldn’t make room for deleted every cached image and was rejected anyway. Eviction now frees only what’s needed and rejects up front when evicting can’t help.
• Fixed: orka imagecache remove could stay RemoveFailed on every retry when the tag had already been deleted by an earlier, timed-out call. It now reports not found and clears the record.
• Fixed: Deploying a VM to a node without enough disk space reported Unable to deploy the VM as the underlying VM process has crashed. The VM now fails with Not enough disk space on node <NODE> to deploy the VM, followed by the space the VM needs and the space available, and the pod records a FailedCreate event with the same error.
• Fixed: Concurrent VM deployments and image pulls on the same node each checked free space without counting what the others were still writing, so a node could run out of disk mid-pull. Each operation now reserves the space it still needs until it finishes.
• Fixed: Cache eviction could delete the image a VM was being created from, so the deployment failed with The file "disk.img" couldn't be opened. Eviction now skips images that an in-progress deployment is using.
• Fixed: If a node ran out of disk space while importing an image, for example during two imports at once, Orka could keep the incomplete image instead of failing the import, and never download it again. VMs deployed from it on that node failed with Unable to deploy the VM as the underlying VM process has crashed. Orka now fails the import, and re-imports a cached image that’s shorter than its full size.
• Fixed: After a node evicted cached images to make room, the evicted images could still show as Ready in orka imagecache output until the next cache change. The node’s image list now refreshes after every deployment and after failed cache adds and removes.
• Fixed: Eviction could empty the cache and still reject the operation, because macOS reports freed disk space a few seconds late. Orka now counts the space eviction reports as freed.
• Fixed: Removing a large cached image could fail with DeadlineExceeded even though the removal completed on the node. Image removals now wait for the node to finish.
• Fixed: Creating a service account token could return an unhelpful error instead of a timeout error when the token wasn’t ready in time.
• Fixed: Tagging, untagging, or changing the namespace of a node could fail with 409 Conflict if the operator updated the node at the same moment. These requests now retry against the latest node state.
• Fixed: With bridged networking, a newly deployed VM could report the previous VM’s IP address, leaving it intermittently unreachable over SSH at the IP Orka returned.
• Fixed: On macOS 26.6.2 hosts, if macOS restarted its window server, the node could lose its GUI session. Running VMs kept running, but no new VMs could start until someone logged in to the node manually. Orka now restores the session before starting a VM.
• Fixed: In 3.7.0-alpha, when an emulator’s pod was removed, Orka could recreate it before the old pod finished terminating. The emulator could then be recreated more than once, or the replacement could fail to start on a port the old emulator still held.
• Fixed: After you commit changes to an existing image under the same name and tag, orka imagecache add could report the image as already cached on nodes where it had been cached automatically by a VM deployment, and skip re-caching it. imagecache add now re-caches the updated image on those nodes.

Security

• Updated golang.org/x/net (CVE-2026-78669), the Web UI’s npm dependencies, and the TLS certificate service’s proxy-addr and axios dependencies to address HIGH and CRITICAL vulnerabilities.

Known issues