Skip to content


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> <VM name>!

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.