Orka 3.3 Release Notes

New Features

• Orka Burst is now available to customers, providing dedicated, on-demand access to elastic cluster capacity as needed. If you are interested in adding burst nodes to your account, please get in touch with MacStadium through your Account Portal.
• Component versions are now shown with the orka3 versionand orka3 node list -o wide commands.
• Orka worker nodes are upgraded to macOS 15.5.

Fixes and Improvements

• Orka has been updated from Kubernetes v1.30 to v1.33. Upgrade Information.
  • Internal upgrades to Kubernetes networking components for greater stability on the control plane.
• Orka now handles the permission alert for non-privileged applications in Sequoia 15.4.
  • Starting with macOS Sequoia, macOS triggers a graphical permissions alert whenever a non-privileged application attempts to communicate with anything on the local network (e.g., pulling an image from an OCI registry hosted on a separate machine on the local network). As a result of this change, the Orka Engine is now deployed as a LaunchDaemon.
• Custom certificates uploaded by clients will persist on API restart and upgrades.
• VMs now generate unique identifiers under Apple's guidelines—more details on the impact of this change in the Known Issues section.
• All fixes released in the Orka 3.2 series are included. 3.2.2 3.2.1

Known Issues

❗️

If you implement code signing workflows in Orka this message pertains to you. Please consider your workflows before deciding to upgrade to 3.3.0

The 3.3.0 release implements behaviors to align with Apple’s guidelines for Virtualization regarding identifiers, as discussed in VZMacMachineIdentifier | Apple Developer Documentation, such that VMs are always created with a unique machine identifier.

In previous versions of Orka, when creating a new macOS VM using orka3 vm deploy --image $OCI_IMAGE or cloning an existing VM, the new VM inherited the machine identifier from the source image or VM. This change conflicted with Apple’s guidelines and was updated in the Orka 3.3.0 release to align with Apple's official guidelines.

Due to this change and other code signing workflows in macOS 15 (see: Apple Developer Forum) that depend on a persistent (or repeatable) machine identifier may fail, as provisioning profiles can no longer be reused across newly created or cloned VMs. Teams using these workflows should regenerate profiles for each VM or consider alternate provisioning strategies that account for dynamic identifiers.

Subsequent releases of Orka will offer an alternative approach to ensure that code signing workflows can execute in VMs.