---
title: "Anka CI Architecture: From Layered Images to Disposable macOS Builds"
description: "Anka is a Docker-like macOS virtualization layer for disposable CI environments. This architecture shows how images, Mac hosts, snapshots, build agents, and artifacts connect."
---

# Anka CI Architecture: From Layered Images to Disposable macOS Builds

**Type:** [Architecture](https://yomu.fyi/visual-explainers/category/architecture.md)

![Layered architecture showing Anka images moving from registries to Mac hosts, where Buildkite agents clone and boot temporary macOS VM snapshots, run builds, upload artifacts, and delete the VMs.](https://yomufyi.s3.us-east-1.amazonaws.com/visual-explainers/143ef5dd-acaa-45fa-837e-4e9bceb00fa1/image-d58cf5fc-e34a-487a-8486-bc02099c128a.webp)

> Anka is a Docker-like macOS virtualization layer for disposable CI environments. This architecture shows how images, Mac hosts, snapshots, build agents, and artifacts connect.

## Explanation

Anka packages macOS build environments as layered images that can be pushed to registries and pulled across MacStadium data centers. Buildkite agents clone temporary snapshots onto Mac hosts, boot suspended VMs, run the build, upload artifacts, and delete the environment. The architecture makes the isolation and horizontal-scaling model visible while highlighting the remaining operational constraint: capacity is manually adjusted, so spiky demand can still create queue time.

## FAQ

### Why use temporary VM snapshots instead of a shared macOS build environment?

The Anka setup clones temporary snapshots, runs each build in a disposable VM, uploads artifacts, and deletes the VM afterward. Shopify’s reported design avoids the shared-storage single point of failure and makes Xcode and macOS upgrades easier.

### Where does Anka CI scaling still need operational attention?

The architecture can scale across Mac hosts and two MacStadium data centers, but capacity remains manually adjusted. Spiky demand can therefore increase queue times even when VM boot is reported to take under a second.

### What is the role of layered images and local storage?

Layered macOS images are pushed to registries and pulled across data centers, while the described Mac Mini setup uses local storage for its VM. Agents then clone snapshots rather than rebuilding each environment from scratch.

**Tags:** [Anka](https://yomu.fyi/topic/anka.md), [Architecture](https://yomu.fyi/topic/architecture.md), [CI/CD](https://yomu.fyi/topic/ci-cd.md), [Deployment](https://yomu.fyi/topic/deployment.md), [Docker](https://yomu.fyi/topic/docker.md)

## Related reading

### [Database Branching in Postgres: Git](https://yomu.fyi/post/database-branching-in-postgres-git.md)
- Company: [Databricks](https://yomu.fyi/company/databricks.md)
- Author: Susan Pierce
- Published: Sep 18, 2026
- Type: Problem & solution

Shared staging databases often drift as schemas diverge, test data accumulates, and developers avoid creating isolated environments because traditional pg\_dump copies are slow and expensive. Databricks Lakebase Postgres addresses this with database branching, which creates fully isolated environments from a parent’s exact schema and data at a point in time. Branches use copy-on-write: they share underlying versioned storage until a branch changes, then record only new data, while each branch has independent compute and a separate connection string. Idle branches scale compute to zero, and storage cost tracks changes rather than the full database size. This supports per-developer, per-pull-request, per-test-run, and recovery workflows, including point-in-time branching within the restore window, with the source describing branch creation through the console, CLI, or API in under a minute.


### [MLOps Frameworks: A Complete Guide to Tools and Platforms for Production ML](https://yomu.fyi/post/mlops-frameworks-a-complete-guide-to-tools-and-platforms-for-productio.md)
- Company: [Databricks](https://yomu.fyi/company/databricks.md)
- Author: Databricks Staff
- Published: Sep 18, 2026
- Type: Explainer

The guide explains how MLOps frameworks close the gap between notebook experimentation and reliable, scalable machine-learning production by applying automation, version control, and continuous delivery across the lifecycle. It describes experiment tracking, model registries, workflow orchestration, feature stores, deployment and serving, and monitoring as the capabilities needed to make training reproducible, prevent training-serving skew, automate pipelines, and detect degradation after release. MLflow is presented as a modular open-source option with Tracking, Model Registry, Models, and Projects, supporting run history, lifecycle stages, standardized packaging, and reproducible execution across environments. Kubeflow suits Kubernetes-standardized organizations and large distributed GPU workloads, while Metaflow, cloud-native services, and unified platforms such as Databricks are positioned as alternatives according to developer experience, cloud alignment, or operational preferences.


### [How Equinix cut operational overhead with a shared services architecture on Amazon EKS](https://yomu.fyi/post/how-equinix-cut-operational-overhead-with-a-shared-services-architectu.md)
- Company: [AWS](https://yomu.fyi/company/aws.md)
- Author: Chhavi Kaushik
- Published: Sep 17, 2026
- Type: Problem & solution

Equinix replaced its self-managed Kubernetes environment on Amazon EKS to address operational sprawl caused by independently managed clusters and inconsistent infrastructure practices. The new shared services architecture assigns platform ownership to a cloud operations team while application teams focus on business services. It uses separate Workloads, Platform, and Network accounts: workloads run across two Availability Zones with ALB, Gateway API, Cilium, and Hubble, while shared data services, GitHub Runners, and platform services reside in the Platform account. The Network account provides cross-account and multi-Region connectivity through AWS Transit Gateway, Route 53 Resolver, and Direct Connect. Equinix reports 40% lower operational overhead, 4x higher deployment frequency, and adoption of a unified architecture across multiple business organizations.


### [Scaling iOS CI with Anka](https://yomu.fyi/post/scaling-ios-ci-with-anka.md)
- Company: [Shopify](https://yomu.fyi/company/shopify.md)
- Author: Sander Lijbrink
- Published: Jul 11, 2018
- Type: Problem & solution

Shopify needed a unified CI/CD system that could give iOS developers the same reliable, disposable build environments already used for Linux and Android projects. An earlier VMware ESXi setup used a shared storage area network, but its maintenance burden and write throughput limit created stability and scalability problems. The replacement uses Anka, a Docker-like macOS virtualization layer built on Apple’s Hypervisor.framework: one Core i7 Mac Mini runs one VM with local storage, while layered images are pushed to registries and pulled across two MacStadium data centers. Buildkite agents clone temporary snapshots, boot suspended VMs in under a second, run steps, upload artifacts, and delete the VMs afterward. Shopify reports about 350 iOS build jobs per hour for roughly 60 iOS developers, with easier Xcode and macOS upgrades, no shared-storage single point of failure, and horizontal scaling, although capacity remains manually adjusted and spiky demand can increase queue times.