#Deployment Zones
A deployment zone is the place your virtual machines actually run. Every organization on Rudder Virt is bound to exactly one zone, and every VM the organization's students touch is built, cloned, and graded inside that zone.
You have two choices for where a zone lives.
#Hosted by Rudder Virt
Rudder Virt operates its own hosted zones. When you sign up, your organization defaults to one of these. There is nothing to deploy and nothing to maintain. We run the underlying Kubernetes cluster, the hypervisor, and the message broker; you log in and use the product.
Pick a hosted zone when you want the shortest path to a working classroom, when you do not have on-premises infrastructure, or when you do not want to operate it yourself.
#Self-hosted with Aileron
You can also stand up your own zone on infrastructure you control. The component you deploy is called Aileron. Aileron is the controller that turns Rudder Virt commands into running VMs. It runs on a Kubernetes cluster with KubeVirt installed, and it talks to the Rudder Virt UI through a NATS broker that sits next to it.
What you operate in a self-hosted zone:
- A Kubernetes cluster with KubeVirt installed.
- A NATS broker reachable from both Aileron and the Rudder Virt UI.
- The Aileron deployment itself, configured with credentials to the cluster and the broker.
What Rudder Virt still operates: the application UI, your account and organization data, the module library, and the autograder. Self-hosting moves the compute, not the product.
Pick a self-hosted zone when you have compliance, latency, or cost reasons to keep VM workloads on your own hardware, or when you want to run modules against networks and devices you cannot expose to a third party. For the operator's view of running one, see Self-hosting Aileron.
#What lives in a zone
A zone is the boundary for compute and the build artifacts produced from that compute.
| Resource | Scoped to a zone? |
|---|---|
| Organizations | Yes. One zone per organization. |
| Student VMs | Yes. They run on the org's zone. |
| Module builds | Yes. A module that has been built in zone A is not automatically available in zone B. |
| Module library entries (the source) | No. The same module definition can be promoted into multiple zones. |
| Users, classes, grades | No. These are application-level and live in Rudder Virt regardless of zone. |
The practical consequence is that a module authored once can be promoted to whatever zones need it, but the binary disk images that students clone are produced and stored per zone.
#Picking and switching zones
A superuser registers a zone in the admin panel and decides whether it is public (selectable by anyone creating an organization) or restricted. When someone creates a new organization, the zone is chosen at that point and is part of the organization's configuration thereafter. Moving an existing organization to a different zone is an administrative action; it requires rebuilding any modules that organization uses in the new zone.
If you are unsure which zone you are on, ask your organization admin or open the organization's settings page.
#Further reading
- KubeVirt documentation for the hypervisor that Aileron drives.
- NATS JetStream for the transport between Aileron and Rudder Virt.
- Self-Hosting Rudder Virt — We offer a self-hosted deployment zone by installing Rudder Virt OS on a bare-metal server you own. Self-hosting moves the compute — the box that runs student VMs — onto your hardware. The UI, accounts, module library, and autograder definitions still live at ruddervirt.com.