MAAS
By Canonical
MAAS (Metal as a Service) is an open-source tool from Canonical that turns a collection of physical servers into a cloud-like, on-demand provisioning pool, letting administrators discover, commission, and deploy operating systems onto…
Definition
MAAS (Metal as a Service) is an open-source tool from Canonical that turns a collection of physical servers into a cloud-like, on-demand provisioning pool, letting administrators discover, commission, and deploy operating systems onto bare-metal machines through a web interface or API as if they were cloud instances. It brings the elasticity and self-service model common in public cloud environments to physical data-center hardware.
Overview
Physical servers traditionally required more manual, hands-on provisioning than cloud virtual machines, which can be spun up on demand through an API in seconds. MAAS was built to close that gap for organizations that need bare-metal performance or must keep hardware on-premises but still want cloud-like operational convenience: discover new hardware automatically, commission it to gather its capabilities, and deploy an operating system to it on demand without manual installation steps. Mechanically, MAAS uses PXE booting combined with its own controller architecture, a region controller that manages overall state and a rack controller that handles network-local services like DHCP and TFTP, to discover new machines as they boot, enroll them into inventory, and run a commissioning process that catalogs each machine's CPU, memory, storage, and network interfaces. Once commissioned, a machine can be deployed with a chosen operating system image through the MAAS API, CLI, or web UI, and MAAS can hand the resulting machine off to an orchestration tool like Juju or a Kubernetes installer for further configuration. MAAS occupies a similar space to Cobbler and Foreman in that it automates bare-metal OS provisioning, but it is distinguished by its explicit cloud-like framing: machines are treated as an inventory pool with states like ready, allocated, and deployed, mirroring how a cloud provider models compute instances, rather than simply being individually named hosts. MAAS is also more tightly associated with the Ubuntu and Canonical ecosystem, integrating naturally with tools like Juju for service orchestration on top of provisioned machines. In practice, MAAS is used to build private bare-metal clouds, provision Kubernetes cluster nodes on physical hardware, and manage lab or data-center hardware pools where teams need to rapidly reassign machines between different operating systems or workloads without manual reinstallation each time. The main trade-offs are its closer coupling to the Ubuntu ecosystem, which can be less appealing to organizations standardized on other Linux distributions, and the operational overhead of running region and rack controllers plus supporting network infrastructure. Teams needing bare-metal provisioning without wanting a full cloud-like inventory abstraction sometimes choose the more minimal Cobbler, while those wanting broader lifecycle and configuration-management integration alongside provisioning often choose Foreman instead, leaving MAAS as the strongest fit specifically for teams already committed to Ubuntu and Juju-based operations. Outside that ecosystem, the cloud-like abstraction MAAS offers is less of a natural fit and adds conceptual overhead without a corresponding integration payoff, so teams should weigh that ecosystem alignment alongside the raw feature comparison.
Key Features
- Discovers and commissions bare-metal servers automatically via PXE
- Models physical machines as an on-demand inventory pool, similar to a cloud
- Provides deployment of chosen OS images through API, CLI, or web UI
- Uses region and rack controller architecture for scalable network services
- Integrates with Juju for post-provisioning service orchestration
- Supports network configuration and storage layout customization per machine
- Enables reassignment of machines between workloads without manual reinstall
- Commonly used to provision Kubernetes cluster nodes on physical hardware