Skip to content

Blog

Bridging the gaps with the Tart Guest Agent

We're introducing a new improvement for the Tart usability experience: a Tart Guest Agent.

This agent provides automatic disk resizing, seamless clipboard sharing for macOS guests (a long-awaited feature), and the ability to run commands, without SSH and networking, using the new tart exec command.

As of recently, we include this agent in all non-vanilla Cirrus Labs images, so you likely won't need to do anything to benefit from these usability improvements.

Read on to learn why we chose to implement the agent from scratch in Golang, and which features we plan to add next.

  • in orchard
  • 3 min read

Jumping through the hoops: SSH jump host functionality in Orchard

Almost a year ago, when we started building Orchard, an orchestration system for Tart, we quickly realized that most worker machines will be in a private network, and that VMs will be only reachable from the worker machines themselves. Thus, one of our goals became to simplify accessing the compute resources in a cluster through a centralized controller host.

This effort resulted in commands like orchard port-forward and orchard ssh, which were later improved to support connecting not just to the VMs, but to the worker machines themselves.

Today, we’re making an even further step in this effort: with a trivial configuration, an Orchard controller can act as an SSH jump host to allow connecting to the VMs using just the ssh command like ssh -J <service account name>@orchard-controller.example.com <VM name>!

New dashboard with insights into performance of Cirrus Runners

This month we are celebrating one year since launching Cirrus Runners — managed Apple Silicon infrastructure for your GitHub Actions. During the last 12 months we ran millions of workflows for our customers and now ready to share some insights into price performance of them for our customers.

One of the key difference with Cirrus Runners is how they are getting billed for. Customers purchase Cirrus Runners via monthly subscription that costs $150 per each Cirrus Runner. Each runner can be used 24 hours a day 7 days a week to run GitHub Actions workflows for an organization. If there are more outstanding jobs than available runners then they are queued and executed as soon as there is a free runner. This is different from how GitHub-managed GitHub Actions are billed for — you pay for each minute of execution time.

The benefit of a fixed price is that you can run as many jobs as you want without worrying about the cost. The downside is that you need to make sure that you are using your runners efficiently. This is where the new dashboard comes in handy.

Tart is now available on AWS Marketplace

Announcing official AMIs for EC2 Mac Instances with preconfigured Tart installation that is optimized to work within AWS infrastructure.

EC2 Mac Instances is a gem of engineering powered by AWS Nitro devices. Just imagine there is a physical Mac Mini with a plugged in Nitro device that can push the physical power button!

EC2 M2 Pro

This clever synergy between Apple Hardware and Nitro System allows seamless integration with VPC networking and booting macOS from an EBS volume.

In this blog post we’ll see how a virtualization solution like Tart can compliment and elevate experience with EC2 Mac Instances.

  • in orchard
  • 4 min read

SSH over gRPC or how Orchard simplifies accessing VMs in private networks

We started developing Orchard, an orchestrator for Tart, with the requirement that it should allow users to access virtual machines running on worker nodes in private networks that users might not have access to.

At the same time, we wanted to enable users to access VMs on these remote workers just as easily as they’d access network services on their local Tart VMs.

While these features sound great on paper, they pose a technical problem: how do we connect to the remote workers, let alone VMs running on these workers, if we can’t assume that these workers will be easily reachable? And how do we establish an SSH connection with a VM running on a remote worker through all these hoops?

Announcing Orchard orchestration for managing macOS virtual machines at scale

Today we are happy to announce general availability of Orchard – our new orchestrator to manage Tart virtual machines at scale. In this post we’ll cover the motivation behind creating yet another orchestrator and why we didn’t go with Kubernetes or Nomad integration.

What problem are we trying to solve?

After releasing Tart we pretty quickly started getting requests about managing macOS virtual machines on a cluster of Apple Silicon machines rather than just a single host which only allows a maximum of two virtual machines at a time. By the end of 2022 the requests reached a tipping point, and we started planning.

Changing Tart License

TLDR: We are transitioning Tart's licensing from AGPL-3.0 to Fair Source 100. This change will permit unlimited installations on personal computers, but organizations that exceed a certain number of server installations utilizing 100 CPU cores will be required to obtain a paid license.

Background

Exactly a year ago on February 11th 2022 we started working on Tart – a tiny CLI to run macOS virtual machines on Apple Silicon. Three months later we successfully started using Tart in our own production system and decided to share Tart with everyone.

The goal was to establish a community of users and contributors to transform Tart from a small CLI to a robust tool for various scenarios. Unfortunately, we were not successful in attracting a significant number of contributors. It's important to note that we did have seven individuals who contributed to the development of Tart to the best of their abilities. However, one of the challenges of contributing to Tart is that the skill set required for a contribution is vastly different from the skill set typically possessed by regular Tart users in their daily work. Specifically, a contributor needs to have knowledge of the Swift programming language, as well as a background in operating systems and network stack. This is the reason why 98.8% of the code and all the major features were contributed by Cirrus Labs engineers.