Skip to main content
This page provides compatibility information for Orka clusters, including supported VM operating systems, host requirements, and feature availability. Use this guide to ensure your Orka configuration meets the necessary requirements. Note: Recommended versions of Orka include the latest features and bug fixes.

​
Apple silicon compatibility

Orka 3.6 runs macOS 27 Golden Gate guests on hosts running macOS 26.6.2 or later. macOS 15 hosts aren’t supported for macOS 27 guests. To deploy a macOS 27 VM, use the MacStadium base image ghcr.io/macstadium/orka-images/golden-gate:latest. You can also upgrade an existing VM to macOS 27 in place and save it as a new image. See OCI images: preserve changes for how to save a VM as an image.
macOS 27 VMs need more than 2 GB of RAM to boot. With 2 GB or less, the VM fails to start. MacStadium recommends at least 4 GB. Apple hasn’t published a memory requirement for macOS 27 VMs, so this guidance comes from MacStadium testing. Set memory with --memory (in gigabytes) when you deploy the VM or create a VM config:
As of Orka 3.6, MSDC host nodes default to macOS 26.6.2, the current recommended host OS for new deployments and upgrades. macOS 15.6+ remains the minimum required host version to run a macOS 26 Tahoe guest.
macOS 27 as a host OS isn’t signed off yet. The Required Host Version column above is the minimum host needed to run that guest, not a statement that any later host works.MacStadium’s evaluation found no blockers running Orka on a macOS 27 host, but final validation isn’t complete, so macOS 26.6.2 remains the recommended host OS. One known limitation applies to MacStadium-hosted clusters: macOS 27 no longer allows TCC permissions to be granted programmatically, which affects NFS-hosted images and shared VM storage on newly provisioned hosts. Clusters that don’t use those two features aren’t affected, and neither are Orka Anywhere deployments.Newly delivered Apple silicon hardware ships with macOS 27 preinstalled. MacStadium provisions MSDC host nodes on macOS 26.6.2. If you manage your own hosts and want to run macOS 27, contact MacStadium support first.
Known issue: In-place upgrades to macOS 15.x and 26.x versions inside a VM currently fail, whether you use Software Update or startosinstall:
  • macOS 26.x (for example 26.6 → 26.6.2, or to 26.7): the VM never finishes its first boot after the upgrade restart. Staying below 26.7 doesn’t avoid it.
  • macOS 15.x (for example 15.7.6 → 15.8.1): the VM boots, but macOS can use only about 1.75 GiB of memory, however much the VM is allocated.
In-place upgrades to macOS 27 are not affected. A workaround follows.
Root cause. Since Apple shipped macOS 27.0 on September 14, 2026, an in-place macOS update inside a VM still installs the macOS version you request. However, it also downloads the newest firmware/recovery bundle Apple serves for virtual Macs (macOS 27’s) instead of the one that matches that version. A 26.x guest carrying that firmware never completes its first boot. A 15.x guest boots, but with its usable memory capped. This isn’t Orka-specific: it affects any Apple Virtualization.framework guest, and it doesn’t matter what macOS version the host itself is running. It’s confirmed to fail even on a host already on 26.6.2. Check whether a 15.x VM is affected. After an upgrade, compare the memory macOS can use with the memory the VM has:
Both values are in bytes. hw.memsize_usable should be close to hw.memsize. If it’s around 1879031808 (about 1.75 GiB) on a VM with much more memory, the VM got the newer firmware. An affected VM can’t be repaired in place. Recreate it, then apply the workaround to the new VM before you upgrade it. The same applies to a 26.x VM that never finished its first boot. Workaround. Run this inside the guest of a VM you’re about to upgrade, before you start the upgrade. Download the full installer first, then block the hosts Apple uses to serve the newer firmware bundle, so the installer falls back to the one it ships with.
1

Download the full installer

Download it while Apple’s servers are still reachable. Replace <MACOS_VERSION> with the version you’re upgrading to, for example 26.7 or 15.8.1:
2

Block the firmware download

3

Run the installer

Use the installer for your target version. Replace <ADMIN_USER> with an administrator account on the VM. --stdinpass reads that account’s password from standard input.For macOS 26.x:
For macOS 15.x:
Check /var/log/install.log for No SFR update was found on the server, using bundled SFR to confirm the fallback took effect. The VM reboots into the new version in about 15 to 20 minutes.
4

Verify and unblock

On macOS 15.x, run sysctl hw.memsize hw.memsize_usable and confirm the two values are close. Then remove the six lines you added to /etc/hosts. Otherwise Software Update and other Apple downloads inside the guest stay blocked.
Contact MacStadium Support if you hit something the workaround doesn’t resolve.

​
M4 compatibility requirements

  • Recommended Host OS Update: MacStadium recommends upgrading Host OSes with M4 to at least macOS 15.2. This resolves compatibility problems with older VM OSes.
  • Known Issue: If the Host OS is earlier than macOS 15.2, VM OSes older than macOS 13.4 will not start.
  • Alternative Solution: If upgrading the Host OS to 15.2 is not possible, use namespaces or tags to differentiate hosts with M4 from those using M2 or M1. Then, route workloads requiring VM OSes older than macOS 13.4 to compatible hosts.

​
OCI image overview

The Open Container Initiative (OCI) is an open standard for container formats and runtimes. MacStadium provides OCI-formatted images for Apple silicon-compatible virtual machines, which are available on OrkaHub. You can deploy VMs using compatible images from public or private registries and store your own images in any OCI-compliant registry. For more information on OCI Images, see OCI Images

​
Intel compatibility (legacy)

Orka 3.6 is the last release to support Intel. Apple’s optimization for Intel effectively ended with macOS 14 (Sonoma), and Intel support in macOS is being phased out. In line with this trajectory, Orka 4.0 and later run on Apple silicon only.MacStadium will continue to support Orka 3.6, including its Intel code paths, for MacStadium deployments through March 2028. During this window we maintain existing Intel functionality but do not plan further Intel performance improvements or optimizations. Intel guest OS support is validated through macOS 14 (Sonoma); macOS 15 (Sequoia) may run but carries known performance limitations that we will not address, and macOS 26 (Tahoe) and later are not supported on Intel.If you still run Intel workloads, we recommend planning your migration to Apple silicon and completing the transition by December 2027.

​
What changes in Orka 4.0

Orka 4.0 removes the Intel-only surface from the CLI, the API, the Web UI, and kubectl:
  • CLI: the iso and remote-iso command groups, vm start, vm stop, vm suspend, vm resume, vm revert, and image generate are removed. So are the --iso, --gpu, --disable-net-boost, --legacy-io, and --system-serial flags on vm deploy and vm-config create.
  • API: the ISO, remote ISO, and image upload and download endpoints are removed, along with VM exec and image generate. Requests that turn on an Intel-only setting (iso, systemSerial, gpuPassthrough: true, or legacyIO: true) fail with an error such as iso is not supported as of Orka 4.0, which no longer supports Intel VMs.
  • kubectl: the admission webhook rejects new VMs and VM configs that use an Intel image (Intel VMs are not supported as of Orka 4.0) or turn on an Intel-only setting. netBoost is accepted with any value and ignored, because network boost is always on for Apple silicon.
  • Upgrades: a cluster that still has Intel worker nodes can’t upgrade to Orka 4.0. The upgrade checks for Intel nodes and stops before making any changes, so remove the Intel nodes from the cluster first, or keep the cluster on Orka 3.6.
For the full list, see the Orka 4.0.0 release notes. The rest of this section, and the Intel sections that follow, apply to Orka 3.6 and earlier.
  • Note: macOS 26 (Tahoe) will not be supported on Intel.

​
Intel image format (legacy)

Intel images are available through a remote network storage mount within MacStadium’s infrastructure. These images are designed for Intel-based virtual machines, and can be accessed directly from the mounted storage.
  • By default, GPU passthrough is disabled for VM configurations and VMs. When you enable GPU passthrough for an Intel VM, this automatically disables VNC for the VM. Make sure that you will be able to access the VM by SSH or Apple Screen Sharing before enabling GPU passthrough.