Now available: Orka 3.0 - Easier to use, faster builds, safer access.

Optimize Image Size and Disk Usage in Anka

Learn how Anka is similar to Docker, and how you can leverage those similarities for CI/CD pipeline efficiency in this post.

Chart with up-right direction and Anka logo

Anka, developed by Veertu Inc., is one of three macOS virtualization layer technologies available at MacStadium. It allows users to spin up ephemeral macOS VMs that behave similarly to Linux containers for the sake of automating processes that must execute on certified Mac hardware.

Anka is designed to have a very Docker-like feel, which should make it intuitive for Docker users. In particular, Anka replicates one of the core features of Docker – the management of images according to layers and tags – in its approach to the way that users manage VM templates.

When a user issues the anka create CLI command, he or she is actually creating a VM template from which to spin up one or more VMs, rather than the VM itself. This is an important distinction because these VM templates are pushed to the central registry and template versions are denoted with tags, much like you would push and tag images in Docker.

Once they’ve been pushed to the registry, VM templates can then be pulled to build nodes as layers that are then associated with any existing layers that already exist on the node. This nuance in Anka allows for a significant reduction in the amount of data to be transferred over the network, the amount of data written to disk, and the time required for a given job when pulling a template from the central registry to an associated build node.

These increases in efficiency are possible because if layers of a given template already exist on a given node – say on a second template version – Anka doesn’t need to pull those layers again. Rather, it simply pulls any new layers that are required, and it associates those layers with the template that already exists locally on disk – again, very much like Docker would behave with container images.

Optimizing for Efficiency

To illustrate these potential savings, we’ll walk through the process of creating, pushing, and pulling Anka VM templates efficiently, so as to conserve VM image size and disk usage across the system.

Create a base template in Anka

First, you’ll want to create a template based on your targeted macOS version.

Install dependencies

Next, you’ll need to install your dependencies. To do so, you’ll first need to start the VM:

anka run {templateName} [Args]

Next, you'll need to run the following to collect the IP address of your new VM:

anka show {templateName}

Finally, you can access the running VM via SSH, like so:

ssh anka@<IP_ADDRESS> Password: admin

Once you’re in, you can install whatever your workflow requires in the VM environment.

Stop / Suspend the VM

After installing your dependencies, you'll need to either stop or suspend the VM in order to capture the current state of the updated VM in a new template.

anka stop {templateName}

Stopping the VM is issuing a full shutdown like you would if you pressed the power button on a physical machine. This option incurs a startup penalty of 20-30 seconds when the template starts up; however, it offers a significant reduction in disk usage.

anka suspend {templateName}

Suspending the VM will result in roughly the opposite costs and benefits – a fairly large file is created that represents the state of the VM, which can be spun up almost instantly. Thus, there is a significant reduction in time to start a VM, but there is also a significant increase in disk usage.

To stop or to suspend?

Veertu recommends that VM templates that will be used directly in pipelines – that is, your actual build environment – be suspended. Stopping the VM will be most useful in cases where you need to build intermediate VM templates that will serve as a stepping-off point for multiple build environments that share some, but not all, additional dependencies.

Clone the Stopped/Suspended VM Template

Once the VM is no longer running, you’ll be able to create a template that represents the current state of the updated VM by cloning it locally, like so:

anka clone {sourceTemplate} {newTemplate}

Tag and Push the VM Template

Finally, to make this new VM template available to all build nodes associated with the system, we’ll need to push it to the Anka registry, like so:

anka registry push {vmNameOrUUID} -t {tag}


Anka offers a very Docker-like means of automating ephemeral macOS VMs for CI/CD. Specifically, macOS VM templates exist in Anka as layers, much like Docker images, and versions of these templates are stored according to tags as you would store images in Docker. In order to take advantage of the efficiency gains that Anka’s design offers, users will need to adhere to the general VM template creation workflow provided above.