Skip to main content
How to create VMs on Apple silicon-based nodes (also: Apple ARM-based nodes). Features and limitations.

​
Overview

Orka supports clusters of Apple silicon-based nodes (also: Apple ARM-based nodes) for running CI/CD workflows. On Orka 3.6 and earlier, Apple silicon-based nodes can be added to an existing cluster alongside Intel-based nodes, giving you a mixed Intel and Apple silicon cluster. Orka 4.0 supports Apple silicon nodes only.
Orka 4.0 does not support Intel. A cluster with Intel worker nodes can’t upgrade to Orka 4.0: the upgrade checks for Intel nodes and stops before making any changes. If you run a mixed cluster, stay on Orka 3.6, which MacStadium supports through March 2028, and plan to migrate remaining Intel workloads to Apple silicon. We recommend completing the transition by December 2027. See the compatibility matrix for details.
Supported VM operations on Apple silicon-based nodes include deploy, delete, and list, as well as connecting to a VM via SSH or Screenshare. VMs deployed on Apple silicon-based nodes use Apple silicon images. A VM is deployed on an Apple silicon-based or Intel-based node depending on the chosen image. VMs based on Intel images (with the amd64 type) are deployed on Intel nodes and VMs based on Apple silicon images (with the arm64 type) are deployed on Apple silicon-based nodes. Orka image list showing arm64 and amd64 image types

​
Deployment on Apple silicon-based nodes

When a VM is deployed on an Apple silicon-based node and this is the first time the image is used on that node, the deployment takes longer, about 4 minutes. Further deployments of VMs using the same image on the same node happen almost immediately and take about 5 seconds.
To keep deployment times fast, you might want to make sure you deploy a VM on all nodes every time you create a new image. Keep in mind though, that images are cached on the nodes. If you try to deploy a VM from an image that is not cached and there is not enough space on the node, the oldest cached image(s) will be deleted to free space for the new one.
Below is a full list of features included in the Apple silicon-based support: Orka 3.5.2:
  • Per-instance shared attached disk sizing (AWS via user data; on-prem via Ansible)
  • CLI auto-reads default namespace from kubeconfig context (ORKA_DEFAULT_NAMESPACE override available)
  • macOS 26 Tahoe compatibility fixes (image deletion, copying, tagging)
Orka 3.5.0:
  • macOS 26 Tahoe guest support (requires Sequoia 15.5 host)
  • Harbor OCI storage is now the default for new deployments
  • Bridged networking support (on-prem only)
  • Shared VM storage disabled by default for new deployments
Orka 3.4:
  • Display resolution CLI flags: --display-width, --display-height, --display-dpi on orka vm deploy and orka vm create
  • IPSW VMs default to 1920×1080×96 resolution
Orka 3.3:
  • orka version and orka node list -o wide now show component versions
  • Burst capacity support (elastic on-demand nodes)
  • Harbor OCI registry support added (became default in 3.5)
  • Hardware UUID generation control (3.3.2): consistent or dynamic Hardware UUIDs configurable per cluster
Orka 3.2:
  • macOS 15 Sequoia support
  • Scheduled image caching
  • Apple ID authentication (Apple silicon hosts running Sequoia only; VM must be created from a Sequoia IPSW)
Orka 3.1:
  • Public IP support in CLI and all integrations
  • orka image list -o wide shows disk size and storage size
Orka 3.0:
  • Enable custom pods (formerly, sandboxing)
  • OCI-compatible images
Orka 2.3:
  • VMs - macOS Ventura support, VNC connectivity
Orka 2.2:
  • VMs - VM metadata
  • Images - resize
  • Integration with TeamCity
Orka 2.1:
  • VM port mappings
  • VM Internet Isolation
  • VM Network Isolation
  • Images - copy, rename
  • Storage - shared attached disk, secondary storage
  • Integration with Tekton
Orka 2.0:
  • VM configs - create, get, purge
  • VMs - deploy, delete, list, check status, connect via SSH, connect via Screenshare
  • Nodes - list, check status, list ports, dedicate
  • Images - list, rename, list remote, pull, delete, commit, save
  • Kube accounts - list, create, delete, regenerate, download kube-config
  • Users - all operations
  • Tokens - all operations
  • Logs - all operations
  • Environment checks - all operations
  • Integration with Jenkins, Gitlab, Buildkite, Github Actions, Packer

​
GPU Passthrough and IO Boost

With VMs based on Apple silicon images, GPU Passthrough comes out of the box. Therefore, the corresponding option --gpu is not applicable to them and will be ignored. Orka 4.0 removes the --gpu flag.

​
Limitations

You can deploy up to 2 VMs per Apple silicon-based node. This is an Apple EULA requirement and applies to all Apple silicon hardware generations.
  1. The following operations are not supported on Apple silicon-based nodes:
  • VMs: stop, start, suspend, resume (these are Intel-only operations due to Apple Virtualization Framework limitations, and were removed in Orka 4.0)
  • Images: download, upload
Below is a list of the ones that are not applicable to Apple silicon-based VMs:
  • Images - generate empty storage
  • ISOs - all operations
  • Nested virtualization
  • Bring your own macOS serial number feature
  1. If you deploy a VM on an Apple silicon-based node and try to log in to your iCloud account you might receive an error ‘The action could not be completed’. This is a limitation of the Apple Virtualization Framework. As a workaround, you can download the needed software via a web browser and install it manually.
  2. There are cases reported by customers that some VMs might not be accessed via ScreenShare, but only SSH. Further investigation shows that this is caused by a failed GPU module under the new Apple silicon architecture. There are also some external bug reports related to the issue on the Bitrise forum and in Bitrise support.
  3. VM revert is not supported due to limitations of the Apple Virtualization Framework.
  4. Shared VM storage on Apple silicon-based nodes requires macOS Sequoia or later.
  5. After you resize an Apple silicon-based VM and attempt to upgrade to a newer macOS version, the upgrade might fail or you might experience other issues with your VM. This is a limitation of the Apple Virtualization framework and applies to all macOS versions. Workaround: Upgrade the macOS image before resizing. If you have already resized, deploy a fresh VM from an unresized image and upgrade from there.