MAAS: Metal as a Service

By Kokil Thapa | Last reviewed: September 2026

MAAS: Metal as a Service is Canonical's bare-metal provisioning layer. It turns racks of physical servers into an API-driven pool you can commission, deploy, and recycle like cloud VMs. If you run Linux system administration for production workloads, you have probably wasted hours on manual PXE USB sticks, BIOS walk-throughs, and inconsistent OS images. MAAS removes that toil. This guide covers architecture, install steps, day-two operations, and where MAAS fits against cloud and manual provisioning—written from the perspective of someone who ships and maintains real Ubuntu servers in production.

What is MAAS (Metal as a Service) and how does it work?

MAAS sits between your physical hardware and the workloads you run on top. You register machines, MAAS discovers them through IPMI or Redfish, and the platform drives network boot to install a chosen Ubuntu release. Once deployed, each host gets cloud-init metadata, SSH keys, networking, and storage layout you define in advance.

The control plane splits into two roles. A region controller holds the database, REST API, DNS, and web UI. One or more rack controllers sit on the same L2 network as the machines and relay DHCP, TFTP, HTTP boot, and power commands. Small labs may colocate both roles on one server. Production clusters usually dedicate separate rack controllers per datacenter row or VLAN segment.

Every machine passes through a lifecycle. It enters as New, moves to Commissioning while MAAS runs hardware tests and collects CPU, RAM, disk, and NIC data. After commissioning it becomes Ready. You then Deploy an OS image. Failed nodes land in Broken until you fix firmware or cabling. This state machine is the core reason MAAS beats ad-hoc PXE scripts—you always know what each box is doing.

On projects where I maintain Ubuntu servers with Deployer and GitLab CI, predictable OS baselines matter. A MAAS-deployed host arrives with the same kernel, packages, and SSH keys every time. That consistency cuts deployment debugging. It mirrors what you expect from cloud images, but on hardware you own outright.

Core components you interact with daily

• REST API and CLI — automate machine allocation, deployment, and release from Terraform, Ansible, or custom scripts.
• DHCP and DNS — MAAS owns the provisioning subnet; external DNS integration keeps service records accurate.
• Image management — sync Ubuntu releases from Canonical's mirrors or import custom cloud-init images.
• IPMI / Redfish — power on, power off, and PXE boot without walking to the rack.
• Networking fabric — define VLANs, bonds, and static routes applied at deploy time.

Official reference material lives in the MAAS documentation. Read the commissioning and networking chapters before your first production VLAN change.

How do you install and configure MAAS for bare metal provisioning?

MAAS 3.x runs on Ubuntu 22.04 LTS or 24.04 LTS. Plan a dedicated provisioning subnet isolated from production traffic. A /26 or /25 network is typical for labs. Production datacenters often dedicate a /24 per rack row. Never share the MAAS DHCP scope with an existing corporate DHCP server on the same VLAN—conflicts break PXE boot silently.

Step 1: Install the region controller

On a fresh Ubuntu 24.04 host with at least 4 GB RAM and 50 GB disk, add the MAAS snap or deb package. The snap path is the simplest for new installs in 2026:

sudo snap install maas --channel=3.5/stable
sudo maas init region+rack \
  --database-uri maas-test-db:/// \
  --maas-url http://maas.example.com:5240/MAAS
sudo maas createadmin

Replace the URL with a hostname that resolves inside your datacenter. TLS termination usually sits on Nginx or HAProxy in front of port 5240. For split deployments, run maas init region on the API host and maas init rack on each relay node.

Step 2: Configure DHCP and DNS

In the MAAS UI under Networking → Subnets, select your provisioning VLAN. Enable MAAS-managed DHCP with a range that excludes the rack controller and any IPMI interfaces. Set upstream DNS forwarders—Cloudflare 1.1.1.1 works for labs; use your internal resolvers in production.

Reserve static IPs for rack controllers and the region controller before enabling DHCP. A common mistake is letting the dynamic pool overlap with BMC addresses. IPMI NICs must stay reachable when MAAS power-cycles the main NIC during commissioning.

Step 3: Enlist and commission machines

1. Connect each server's provisioning NIC to the MAAS VLAN.
2. Configure BMC credentials (IPMI username, password, IP) in the MAAS UI or via API.
3. Power on the server; it PXE-boots and appears under Machines → New.
4. Accept the machine, then click Commission.
5. Review collected hardware data, then deploy Ubuntu 24.04 LTS or 22.04 LTS.

Cloud-init user data is where you encode baseline hardening. A minimal example that matches patterns from systemd service unit workflows on freshly provisioned hosts:

#cloud-config
package_update: true
packages:
  - fail2ban
  - ufw
  - git
users:
  - name: deploy
    groups: sudo
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - ssh-ed25519 AAAA...your-key
runcmd:
  - ufw allow OpenSSH
  - ufw --force enable
  - systemctl enable fail2ban

Attach this cloud-init snippet to a MAAS machine configuration or tag. Every deploy inherits it automatically. Validate YAML with a JSON and YAML formatter before pasting—one indentation error fails silently until you inspect cloud-init logs on the host.

Canonical's install walkthrough at Ubuntu Server MAAS install docs covers HA region controllers and PostgreSQL tuning for larger fleets.

How does MAAS compare to cloud VMs and manual bare metal provisioning?

The decision is not MAAS versus cloud. It is about workload fit, cost at scale, and operational maturity. Cloud VMs win for bursty traffic and managed services. MAAS wins when you need bare-metal performance, GPU passthrough, predictable monthly cost on owned hardware, or air-gapped environments.

Nepal-based teams often start on cloud hosting in Nepal because capex and datacenter access are limited. MAAS becomes attractive when you outgrow VPS pricing or need dedicated hardware for database or video workloads. Colocation in Kathmandu or Singapore plus a MAAS rack can beat cloud bills once you hold more than roughly fifteen steady-state servers.

Alternatives exist. Foreman, Cobbler, and Ironic (OpenStack) each provision bare metal. MAAS integrates tightly with Ubuntu and Juju, which lowers friction if your stack is already Canonical-centric. For multi-distro shops, Foreman plus Puppet or Ansible may fit better. MAAS still wins on commissioning UX and the machine lifecycle API.

When should you use MAAS for your infrastructure?

MAAS earns its keep in specific scenarios. Skip it if you run fewer than five physical servers and rarely rebuild them. The learning curve and VLAN planning are not worth it for a single database box under a desk.

Strong use cases include:

• Kubernetes on bare metal — pair MAAS with Kubernetes on bare metal with MetalLB for on-prem clusters without cloud load balancers.
• CI/CD runner farms — GitLab CI or Jenkins agents that need isolated hardware for integration tests.
• Database and cache tiers — PostgreSQL 18 or Redis 8.10 on NVMe with no hypervisor overhead.
• GPU and ML workloads — pass through physical GPUs MAAS commissioned and catalogued.
• Air-gapped or compliance environments — legal, banking, or government workloads that cannot live on public cloud.
• Edge and regional POPs — deploy identical Ubuntu nodes to Kathmandu, Dubai, and Sydney from one MAAS region.

On sister sites I maintain with Deployer 7 and GitLab CI—such as Notary Kathmandu and related legal-tech properties—the production path runs on managed VPS today. If those workloads moved to owned hardware for cost or compliance, MAAS would be my first provisioning layer. The cloud-init plus SSH key pattern maps directly to existing deploy keys and systemd-managed services.

Legal-tech portals with document storage and client data sometimes need data residency guarantees. MAAS lets you prove exactly which physical drives hold which tenant data. Cloud shared tenancy makes that audit trail harder.

When MAAS is the wrong tool

Do not adopt MAAS for ephemeral developer laptops, Windows-heavy fleets (MAAS targets Ubuntu primarily), or environments where you cannot control DHCP on the provisioning VLAN. Managed Kubernetes on AWS EKS or GKE is simpler if you have no hardware to rack.

How do you integrate MAAS with Kubernetes and CI/CD pipelines?

MAAS becomes powerful when machines enter your pipeline automatically. The typical pattern: Terraform or the MAAS CLI allocates machines, Ansible or cloud-init hardens them, then cluster tooling takes over.

Terraform provider workflow

The official MAAS Terraform provider declares machines as code. A simplified resource block:

terraform {
  required_providers {
    maas = {
      source = "canonical/maas"
    }
  }
}

provider "maas" {
  api_url     = "http://maas.example.com:5240/MAAS"
  api_key     = var.maas_api_key
}

resource "maas_machine" "k8s_worker" {
  hostname    = "k8s-worker-01"
  zone        = "default"
  min_cpu_count = 8
  min_memory_mb = 32768
}

resource "maas_machine_deploy" "k8s_worker" {
  machine_id  = maas_machine.k8s_worker.id
  distro_series = "ubuntu/jammy"
  user_data   = file("cloud-init-k8s.yaml")
}

Combine this with self-service infrastructure patterns if you want platform teams to request bare-metal nodes through a higher-level API. MAAS stays the low-level provisioner; Crossplane or custom portals sit above it.

Kubernetes cluster bootstrap

After MAAS deploys Ubuntu nodes, install containerd and kubeadm, or use Canonical Kubernetes (Charmed K8s) with Juju charms. MAAS tags help—tag machines gpu, storage, or compute so cluster autoscaler equivalents pull the right hardware profile.

For Laravel 13 or Symfony 8.1 application tiers, MAAS-provisioned nodes run PHP 8.5 with PHP-FPM behind Nginx. Queue workers and schedulers land on separate MAAS tags so web and batch tiers scale independently. This mirrors how I structure enterprise application deployments on VPS today—just with hardware profiles instead of instance types.

Network boot fundamentals matter when debugging failed commissions. The Linux kernel network booting guide explains PXE, DHCP, and TFTP interactions that MAAS orchestrates under the hood.

Day-two operations checklist

1. Back up the MAAS PostgreSQL database nightly—machine state lives there.
2. Monitor rack controller DHCP lease exhaustion; expand pools before PXE fails.
3. Rotate MAAS API keys used by Terraform the same way you rotate cloud IAM keys.
4. Test IPMI credentials quarterly; stale BMC passwords block power cycling.
5. Keep Ubuntu images synced; stale kernels miss security patches at deploy time.
6. Document VLAN and subnet layout—future you will forget which rack uses which fabric.

Ongoing support and maintenance contracts should include MAAS health checks if clients rely on it for provisioning. A broken rack controller stops all new deploys even when running workloads stay up.

For service discovery after deploy, integrate with Consul or internal DNS—see Consul service discovery and load balancing patterns for the application layer above MAAS.

Key Takeaways

• MAAS: Metal as a Service converts physical servers into an API-managed pool with PXE boot, commissioning, and cloud-init—treat hardware like cloud instances.
• Split region controllers (API and database) from rack controllers (DHCP, TFTP, HTTP boot) for production datacenter layouts.
• Isolate the provisioning VLAN and reserve BMC IPs before enabling MAAS-managed DHCP to avoid silent PXE failures.
• Use cloud-init for baseline hardening so every deployed Ubuntu host matches your security and package standards.
• Pair MAAS with Terraform and Kubernetes when you need repeatable bare-metal clusters, not one-off USB installs.
• Choose MAAS when steady-state server count, performance, or data sovereignty justify owned hardware over public cloud OPEX.

People Also Ask

Is MAAS free to use?

MAAS is open source under AGPL. Canonical offers free usage for up to a limited number of machines and sells support for larger enterprise fleets. Check current licensing on maas.io before planning a hundred-node datacenter. Lab and small production use is typically free.

Does MAAS only support Ubuntu?

MAAS is optimized for Ubuntu LTS releases. You can deploy custom images for other Linux distributions via curtin and cloud-init, but first-class support and tested images target Ubuntu. Windows and ESXi provisioning are out of scope for standard MAAS workflows.

What hardware do I need to run MAAS?

A region controller needs a modest x86_64 server—4 GB RAM minimum, 8 GB recommended, with SSD storage for PostgreSQL. Rack controllers need reliable L2 connectivity to the provisioning VLAN and low-latency access to IPMI networks. Target servers need PXE-capable NICs and working BMC interfaces.

Can MAAS work without IPMI?

Yes, but you lose remote power control. Machines can enlist via PXE on first boot and stay managed afterward. Without IPMI or Redfish, MAAS cannot power-cycle hung nodes remotely—you walk to the rack or use smart PDUs with API control instead.

Build bare-metal infrastructure that scales with your applications

MAAS: Metal as a Service closes the gap between racking servers and running production workloads. You get cloud-style provisioning on hardware you control, with commissioning data, API automation, and Ubuntu images that match the stacks I deploy daily—PHP 8.5, Laravel 13, PostgreSQL 18, Redis 8.10, and GitLab CI pipelines. Start in a lab VLAN, prove one commissioning cycle, then expand rack controllers as your fleet grows.

If you are planning private infrastructure, migrating off pure cloud, or need help wiring MAAS into your deployment pipeline, see the portfolio of production systems I have shipped and the hosting and infrastructure services available for Nepal and remote clients. For API-driven platform design around bare-metal nodes, review API development practices and related reading on gRPC versus REST for internal services. Ready to scope your setup? Contact us to discuss architecture, cost modelling, and a phased rollout plan.