Forem: todoroff

Terraform for Local VMs: A Modern Alternative to Vagrant

todoroff — Wed, 07 Jan 2026 10:45:03 +0000

After 8 years of using Vagrant, I finally made the switch. Not because Vagrant stopped working - it still does what it's always done. But because I found something that fits better into my modern infrastructure-as-code workflow.

Here's the story of how I replaced Vagrant with Multipass + Terraform and never looked back.

The Problem: Vagrant is Showing Its Age

Don't get me wrong - Vagrant revolutionized local development. The idea of "infrastructure as code" for your laptop was groundbreaking in 2010.

But in 2026, I kept hitting the same pain points:

🔧 Provider lock-in
Tied to VirtualBox (slow) or VMware (expensive). Hyper-V support was always "experimental."

📦 Heavy box downloads
Every vagrant up on a new project meant downloading multi-GB box files.

🤔 Different workflow
Vagrantfile syntax is Ruby DSL. My production infrastructure is Terraform. Why maintain two mental models?

Sound familiar?

The Discovery: Multipass + Terraform

Then I discovered Canonical Multipass - a lightweight VM manager from Canonical.

Combined with a Terraform provider, I could:

✅ Use the same IaC approach locally and in production
✅ Native cloud-init support (just like AWS/GCP/Azure)
✅ Simpler setup - no VirtualBox Guest Additions hassles
✅ One workflow to rule them all

Let me show you how to make the switch.

Part 1: Understanding the Difference

Vagrant's Approach

# Vagrantfile
Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/jammy64"
  config.vm.network "private_network", ip: "192.168.56.10"

  config.vm.provider "virtualbox" do |vb|
    vb.memory = "2048"
    vb.cpus = 2
  end

  config.vm.provision "shell", inline: <<-SHELL
    apt-get update
    apt-get install -y nginx
  SHELL
end

Ruby DSL
Provider-specific configurations
Shell provisioners (or Ansible/Chef/Puppet)
Box-based images

Multipass + Terraform Approach

# main.tf
terraform {
  required_providers {
    multipass = {
      source = "todoroff/multipass"
    }
  }
}

resource "multipass_instance" "web" {
  name   = "web-server"
  cpus   = 2
  memory = "2G"
  disk   = "10G"
  image  = "jammy"

  cloud_init = <<-EOT
    #cloud-config
    packages:
      - nginx
  EOT
}

Standard HCL (same as production Terraform)
Cloud-init provisioning (same as cloud VMs)
Image aliases (no giant downloads)

Same result, different philosophy.

Part 2: Setting Up Multipass + Terraform

Step 1: Install Multipass

# macOS
brew install multipass

# Ubuntu/Debian
sudo snap install multipass

# Windows
# Download from https://multipass.run/install
winget install Canonical.Multipass

Verify it works:

multipass version
# multipass   1.14.0

Step 2: Create Your First Terraform Config

Create a new directory and main.tf:

terraform {
  required_providers {
    multipass = {
      source  = "todoroff/multipass"
      version = "~> 1.5"
    }
  }
}

provider "multipass" {
  # Optional: explicit path to multipass binary
  # multipass_path = "/usr/local/bin/multipass"

  # Optional: timeout for commands (default 120s)
  command_timeout = 300
}

resource "multipass_instance" "dev" {
  name   = "my-dev-vm"
  cpus   = 2
  memory = "4G"
  disk   = "20G"
  image  = "jammy"  # Ubuntu 22.04 LTS
}

output "ip_address" {
  value = multipass_instance.dev.ipv4[0]
}

Step 3: Deploy

terraform init
terraform apply

That's it. Your VM is running. ⚡

# Check it
multipass list
# Name       State    IPv4            Image
# my-dev-vm  Running  192.168.64.5    Ubuntu 22.04 LTS

# SSH into it
multipass shell my-dev-vm

Part 3: Migrating Your Vagrantfile

Let's convert a real-world Vagrant setup to Multipass + Terraform.

Before: Vagrant Multi-Machine Setup

# Vagrantfile
Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/jammy64"

  config.vm.define "db" do |db|
    db.vm.hostname = "db-server"
    db.vm.network "private_network", ip: "192.168.56.10"
    db.vm.provider "virtualbox" do |vb|
      vb.memory = "2048"
    end
    db.vm.provision "shell", inline: <<-SHELL
      apt-get update
      apt-get install -y postgresql postgresql-contrib
      sudo -u postgres createuser --superuser vagrant
      sudo -u postgres createdb myapp
    SHELL
  end

  config.vm.define "web" do |web|
    web.vm.hostname = "web-server"
    web.vm.network "private_network", ip: "192.168.56.11"
    web.vm.provider "virtualbox" do |vb|
      vb.memory = "1024"
    end
    web.vm.provision "shell", inline: <<-SHELL
      apt-get update
      apt-get install -y nginx
      echo "upstream api { server 192.168.56.10:5432; }" > /etc/nginx/conf.d/upstream.conf
    SHELL
  end
end

After: Multipass + Terraform

# main.tf
terraform {
  required_providers {
    multipass = {
      source  = "todoroff/multipass"
      version = "~> 1.5"
    }
  }
}

provider "multipass" {}

# Database Server
resource "multipass_instance" "db" {
  name   = "db-server"
  cpus   = 2
  memory = "2G"
  disk   = "10G"
  image  = "jammy"

  cloud_init = <<-EOT
    #cloud-config
    package_update: true
    packages:
      - postgresql
      - postgresql-contrib
    runcmd:
      - sudo -u postgres createuser --superuser ubuntu
      - sudo -u postgres createdb myapp
  EOT
}

# Web Server (depends on DB for its IP)
resource "multipass_instance" "web" {
  name   = "web-server"
  cpus   = 1
  memory = "1G"
  disk   = "5G"
  image  = "jammy"

  cloud_init = templatefile("${path.module}/web-init.yaml", {
    db_host = multipass_instance.db.ipv4[0]
  })

  depends_on = [multipass_instance.db]
}

# Outputs
output "db_ip" {
  value = multipass_instance.db.ipv4[0]
}

output "web_ip" {
  value = multipass_instance.web.ipv4[0]
}

# web-init.yaml
#cloud-config
package_update: true
packages:
  - nginx
write_files:
  - path: /etc/nginx/conf.d/upstream.conf
    content: |
      upstream api {
        server ${db_host}:5432;
      }
runcmd:
  - systemctl restart nginx

Part 4: Advanced Features You'll Love

Snapshots (Save Your Progress!)

One killer feature the Vagrant workflow always lacked: native snapshots.

resource "multipass_instance" "test_env" {
  name  = "test-env"
  image = "jammy"
  # ... config
}

# Take a snapshot before risky operations
resource "multipass_snapshot" "before_upgrade" {
  instance = multipass_instance.test_env.name
  name     = "pre-upgrade-backup"
}

Now you can:

Run your tests
Break things
Restore to snapshot
Repeat

All managed through Terraform state.

File Transfers (No More Provisioners!)

Remember the pain of synced folders and file provisioners?

# Upload config files
resource "multipass_file_upload" "app_config" {
  instance    = multipass_instance.web.name
  source      = "${path.module}/configs/app.yaml"
  destination = "/etc/myapp/config.yaml"
}

# Download logs for analysis
resource "multipass_file_download" "app_logs" {
  instance    = multipass_instance.web.name
  source      = "/var/log/myapp/app.log"
  destination = "${path.module}/logs/app.log"
}

No more:

config.vm.synced_folder headaches
NFS permission issues
VirtualBox Guest Additions breaking
rsync timing problems

Aliases (Quick Access)

Create host-level shortcuts to jump into your VMs:

resource "multipass_alias" "db_shell" {
  name     = "db-psql"
  instance = multipass_instance.db.name
  command  = "sudo -u postgres psql myapp"
}

resource "multipass_alias" "web_logs" {
  name     = "web-logs"
  instance = multipass_instance.web.name
  command  = "tail -f /var/log/nginx/access.log"
}

Now from your host terminal:

db-psql      # Instantly opens psql on db server
web-logs     # Tails nginx logs

No more vagrant ssh web -c "..." gymnastics.

Part 5: Real-World Use Cases

Local Kubernetes Clusters

Want to spin up a full multi-node K3s cluster for testing? I wrote a complete step-by-step tutorial:

📚 Build a Local Kubernetes Cluster in Minutes with Terraform and Multipass

The tutorial walks through:

1 master + 2 worker nodes
Automatic cluster joining via cloud-init
kubectl access from your host machine
Complete working code you can deploy today

Other Common Use Cases

This stack is also perfect for:

🔧 Infrastructure Testing

Test Ansible playbooks across multiple nodes
Validate HAProxy or Nginx load balancer configs
Simulate distributed systems locally

🎓 Learning Labs

Practice Terraform without cloud costs
Learn Linux system administration
Experiment with databases and replication

💻 Development Environments

Reproducible team dev environments
Test upgrades in isolation
Quick throwaway VMs for experimentation

Part 6: Migration Cheat Sheet

Vagrant	Multipass + Terraform
`vagrant up`	`terraform apply`
`vagrant destroy`	`terraform destroy`
`vagrant ssh`	`multipass shell <name>`
`vagrant halt`	(use `multipass stop <name>`)
`vagrant reload`	`terraform apply` (with changes)
`config.vm.box`	`image = "jammy"`
`vb.memory`	`memory = "2G"`
`vb.cpus`	`cpus = 2`
`config.vm.provision "shell"`	`cloud_init = <<-EOT ... EOT`
`config.vm.synced_folder`	`multipass_file_upload` resource
`config.vm.network`	`networks { }` block

Part 7: When to Stick with Vagrant

To be fair, Vagrant still has its place:

✅ Use Vagrant if:

You need non-Ubuntu operating systems (Windows, CentOS, etc.)
You're locked into VMware or Hyper-V for specific reasons
Your team has heavy investment in existing Vagrantfiles
You need VirtualBox-specific features

✅ Use Multipass + Terraform if:

You're working primarily with Ubuntu/Linux
You want a simpler, lighter setup
You want one workflow for local and cloud
You're already using Terraform
You want modern cloud-init provisioning
Resource efficiency is important

Getting Started Today

Ready to make the switch? Here's your 5-minute quickstart:

1. Install Dependencies

# Install Multipass
brew install multipass  # or snap install multipass

# Verify
multipass version

2. Create Your First Config

mkdir my-dev-env && cd my-dev-env

cat > main.tf << 'EOF'
terraform {
  required_providers {
    multipass = {
      source = "todoroff/multipass"
    }
  }
}

resource "multipass_instance" "dev" {
  name   = "dev-box"
  cpus   = 2
  memory = "4G"
  disk   = "20G"
  image  = "jammy"

  cloud_init = <<-EOT
    #cloud-config
    packages:
      - git
      - curl
      - build-essential
    runcmd:
      - echo "Dev environment ready!" > /home/ubuntu/welcome.txt
  EOT
}

output "ip" {
  value = multipass_instance.dev.ipv4[0]
}
EOF

3. Deploy

terraform init
terraform apply -auto-approve

4. Access Your VM

multipass shell dev-box
cat ~/welcome.txt
# Dev environment ready!

That's it. You're running a modern, fast, Terraform-managed local development environment.

Resources

Terraform Provider: registry.terraform.io/providers/todoroff/multipass
GitHub Repository: github.com/todoroff/terraform-provider-multipass
Multipass Official: multipass.run
Example Configurations: GitHub Examples

Conclusion

Switching from Vagrant to Multipass + Terraform was one of the best decisions I made for my local development workflow.

What I gained:

🔧 Simpler setup (no Guest Additions, NFS issues, etc.)
🔄 One IaC workflow for everything
📸 Native snapshot support
🎯 Cloud-native provisioning with cloud-init

What I lost:

Multi-OS support (Ubuntu-only)
...that's about it

If you want a modern, Terraform-native approach to local VMs, give this a try.

Have questions about migrating your Vagrant setup? Drop them in the comments! I'm happy to help with specific migration scenarios.

Found this useful? Consider ⭐ starring the provider on GitHub - it helps others discover it!

What's your local development setup? Still on Vagrant, Docker Compose, or something else entirely? Let me know in the comments! 👇

Build a Local Kubernetes Cluster in Minutes with Terraform and Multipass

todoroff — Sun, 23 Nov 2025 00:05:51 +0000

Are you looking for a way to spin up a lightweight, throwaway Kubernetes cluster on your local machine without the overhead of Docker Desktop or Minikube? Or maybe you want to simulate a multi-node environment to test node affinity and failover?

In this article, we'll show you how to build a multi-node K3s cluster completely from code using the Multipass Terraform Provider.

Why This Stack?

Multipass: Canonical's lightweight VM manager for Linux, Windows, and macOS. It spins up Ubuntu instances in seconds.
Terraform: The industry standard for Infrastructure as Code (IaC). It manages the lifecycle, dependencies, and configuration of your VMs.
K3s: A highly available, certified Kubernetes distribution designed for production workloads in unattended, resource-constrained, remote locations or inside IoT appliances.

By combining these, you get a reproducible, codified local lab environment that you can spin up and tear down with a single command.

The Project: A 3-Node K3s Cluster

We are going to build:

1 Master Node: Runs the K3s control plane.
2 Worker Nodes: Join the cluster automatically.
Automatic Wiring: Terraform will handle passing the master's IP and a shared secret to the workers.

Prerequisites

Install Multipass
Install Terraform
Initialize a new directory for your project:
```
mkdir k3s-lab && cd k3s-lab
```

The Terraform Configuration

Create a file named main.tf and paste the following code. We're using the todoroff/multipass provider to manage our VMs.

terraform {
  required_providers {
    multipass = {
      source  = "todoroff/multipass"
    }
  }
}

provider "multipass" {
  # Increase timeout for image downloads and initialization
  command_timeout = 600 
}

# 1. Define a shared secret for the cluster
locals {
  k3s_token = "my-super-secret-shared-token-12345"

  # Cloud-init script for the master node
  # Installs K3s server, creates a wrapper script for kubectl, and sets the token
  master_cloud_init = <<-EOT
    #cloud-config
    package_update: true
    package_upgrade: true
    write_files:
      - path: /usr/local/bin/k3s-kubectl-wrapper
        permissions: '0755'
        content: |
          #!/bin/sh
          sudo k3s kubectl "$@"
    runcmd:
      - curl -sfL https://get.k3s.io | K3S_TOKEN=${local.k3s_token} sh -s - server --cluster-init
  EOT
}

# 2. Create the Master Node
resource "multipass_instance" "k3s_master" {
  name   = "k3s-master"
  cpus   = 2
  memory = "2G"
  disk   = "10G"
  image  = "jammy" # Ubuntu 22.04 LTS

  cloud_init = local.master_cloud_init
}

# 3. Create Worker Nodes
# These depend on the master because they need its IP address
resource "multipass_instance" "k3s_worker" {
  count  = 2
  name   = "k3s-worker-${count.index + 1}"
  cpus   = 1
  memory = "1G"
  disk   = "5G"
  image  = "jammy"

  # Cloud-init script for workers
  # Uses the master's IP (from Terraform state) to join the cluster
  cloud_init = <<-EOT
    #cloud-config
    package_update: true
    runcmd:
      - curl -sfL https://get.k3s.io | K3S_URL=https://${multipass_instance.k3s_master.ipv4[0]}:6443 K3S_TOKEN=${local.k3s_token} sh -
  EOT

  depends_on = [multipass_instance.k3s_master]
}

# 4. Create a convenient alias to run kubectl from your host
# We use a wrapper script to handle argument passing correctly via alias
resource "multipass_alias" "kubectl" {
  name     = "k3s-kubectl"
  instance = multipass_instance.k3s_master.name
  command  = "/usr/local/bin/k3s-kubectl-wrapper"
}

# 5. Output the node IPs
output "cluster_nodes" {
  value = {
    master  = multipass_instance.k3s_master.ipv4
    workers = multipass_instance.k3s_worker[*].ipv4
  }
}

How It Works

cloud_init Magic: We use Terraform's local variables to construct a cloud-init script. This script runs on first boot.
- On the master, it downloads and installs K3s in server mode. It also creates a helper script /usr/local/bin/k3s-kubectl-wrapper to make running kubectl commands easier via alias.
- On the workers, it installs K3s and immediately joins the cluster using the K3S_URL environment variable.
Dynamic Configuration: Notice ${multipass_instance.k3s_master.ipv4[0]} in the worker's cloud-init. Terraform waits for the master to be created, grabs its first IPv4 address, injects it into the worker's configuration, and then creates the workers. No manual copy-pasting required!
Aliases: The multipass_alias resource creates a k3s-kubectl command on your host machine that invokes the wrapper script on the master node.

Deploying the Lab

Initialize Terraform:
```
terraform init
```
Apply the Configuration:
```
terraform apply
```
Type yes when prompted.

Terraform will spin up the VMs. It might take a minute or two for the VMs to boot and for K3s to install.

Using Your Cluster

Once Terraform finishes, wait about 60 seconds for the cloud-init scripts to complete installation inside the VMs.

Check the Nodes:
You can run kubectl commands directly from your terminal using the alias we created:

multipass k3s-kubectl get nodes

You should see something like:

NAME           STATUS   ROLES                       AGE   VERSION
k3s-master     Ready    control-plane,etcd,master   2m    v1.28.2+k3s1
k3s-worker-1   Ready    <none>                      1m    v1.28.2+k3s1
k3s-worker-2   Ready    <none>                      1m    v1.28.2+k3s1

Deploy a Test Workload:
Deploy a simple Nginx server to verify everything is working:

multipass k3s-kubectl create deployment nginx --image=nginx
multipass k3s-kubectl expose deployment nginx --port=80 --type=NodePort

Cleanup

When you're done with your lab, you don't need to manually delete VMs or clean up files. Just run:

terraform destroy

This will stop and delete all the Multipass instances and remove the aliases, leaving your machine clean.

Conclusion

The Multipass Terraform Provider turns your local machine into a flexible cloud environment. Whether you're testing Kubernetes, setting up a complex microservices mesh, or just need a clean Linux sandbox, you can define it all in code.

Check out the provider documentation for more resources like multipass_mount and multipass_snapshot to take your local labs to the next level!

Or some of the examples in the provider repository: https://github.com/todoroff/terraform-provider-multipass

Multipass + Terraform: Modern VM Automation Guide

todoroff — Tue, 18 Nov 2025 10:09:46 +0000

This article introduces the todoroff/multipass Terraform provider: a modern, plugin-framework-based provider that exposes Multipass features as declarative infrastructure. We’ll walk through:

Basic instance management
Multiple NICs and static IPs
Inline and templated cloud-init
File upload/download without provisioners
Patterns for Ansible and dev/CI workflows

The examples target Terraform ≥ 1.6 and Multipass ≥ 1.13.

Why another Multipass provider?

There is an existing Multipass provider out in the wild (larstobi/terraform-provider-multipass), but users have requested features like:

Network interfaces & predictable IP handling
Better cloud-init ergonomics
More expressive networking and file transfer support

This provider focuses on:

Rich instance schema: CPU, memory, disk, multiple networks, mounts, cloud-init (file or inline), auto-recovery.
Networking primitives: networks block that maps directly to multipass networks and supports multiple NICs with explicit MACs.
First-class cloud-init: cloud_init_file or cloud_init inline, with clear mutual exclusion and templating support.
File workflows: multipass_file_upload and multipass_file_download as alternatives to brittle provisioners.
Clean diagnostics: backed by a dedicated CLI parsing layer for better error messages.

Getting started

Add the provider to your Terraform configuration:

terraform {
  required_providers {
    multipass = {
      source  = "todoroff/multipass"
      version = ">= 1.4.0"
    }
  }
}

provider "multipass" {
  # Optional overrides
  multipass_path  = "/usr/bin/multipass"
  command_timeout = 180          # seconds
  default_image   = "lts"        # fallback image alias
}

A basic VM with networking and an alias

First, let’s create a simple dev box, attach it to a host NIC, and expose a convenient alias:

resource "multipass_instance" "dev" {
  name   = "dev-box"
  image  = "lts"
  cpus   = 2
  memory = "4G"
  disk   = "15G"

  # Attach to a specific host NIC from `multipass networks`
  networks {
    name = "en0"
  }

  # Optional host mount
  mounts {
    host_path     = "/home/USERNAME/projects"
    instance_path = "/workspace"
    read_only     = false
  }

  primary      = true
  auto_recover = true
}

resource "multipass_alias" "shell" {
  name     = "dev-shell"
  instance = multipass_instance.dev.name
  command  = "bash"
}

output "dev_ip" {
  value = multipass_instance.dev.ipv4
}

networks block: Binds the VM to a host network (e.g. en0 on macOS) discovered via multipass networks.
ipv4 output: Exposes the VM’s IP(s) for use in other Terraform resources or inventories.

Multiple NICs and deterministic MACs

Multipass supports multiple NICs per instance; this provider lets you express that with repeated networks blocks. Each entry becomes a --network flag under the hood.

resource "multipass_instance" "router" {
  name   = "lab-router"
  image  = "22.04"
  cpus   = 2
  memory = "2G"
  disk   = "8G"

  # NIC 1: Wi-Fi
  networks {
    name = "en0"
    mode = "manual"
    mac  = "52:54:00:4b:ab:bd"
  }

  # NIC 2: Wired
  networks {
    name = "en5"
    mode = "manual"
    mac  = "52:54:00:4b:ab:cd"
  }
}

This pattern is useful when you care about:

Stable MACs for DHCP reservations.
Traffic separation across multiple host interfaces.
Lab setups that mimic routers or multi-homed hosts.

Static IPs with cloud-init + Netplan

If you want static IPs inside the guest, the recommended approach is:

Use a fixed MAC in the networks block.
Use cloud-init to write a Netplan config that assigns a static IP to that MAC.
Apply Netplan on boot.

Here’s a complete example using inline cloud-init:

resource "multipass_instance" "static" {
  name   = "lab-node-1"
  image  = "22.04"
  cpus   = 1
  memory = "2G"
  disk   = "5G"

  # Stable MAC on a specific host NIC
  networks {
    name = "en0"
    mode = "manual"
    mac  = "52:54:00:4b:ab:bd"
  }

  # Inline cloud-init configuring a static IPv4 via Netplan
  cloud_init = <<-EOT
    #cloud-config
    write_files:
      - path: /etc/netplan/10-custom.yaml
        permissions: "0644"
        content: |
          network:
            version: 2
            ethernets:
              extra0:
                dhcp4: no
                match:
                  macaddress: "52:54:00:4b:ab:bd"
                addresses: ["192.168.64.97/24"]
    runcmd:
      - netplan apply
  EOT
}

output "static_ip" {
  value = multipass_instance.static.ipv4
}

cloud_init is a normal Terraform string; you can also feed it from file() or templatefile().
The instance’s ipv4 attribute will include the static address once cloud-init finishes.

For more complex cloud-init content, the provider also supports:

cloud_init_file: path to a YAML file on disk.
cloud_init: inline YAML (mutually exclusive with cloud_init_file).

Template-driven cloud-init (CI runner example)

The provider ships with a cloud-init-lab example that shows how to render cloud-init from a template and assign it to instances.

A simplified pattern:

locals {
  rendered_cloud_init = templatefile("${path.module}/cloud-init.tpl", {
    username = "ci-runner"
    motd     = "Runner ready!"
  })
}

resource "multipass_instance" "runner" {
  name   = "ci-runner"
  image  = "lts"
  cpus   = 2
  memory = "3G"
  disk   = "12G"

  cloud_init = local.rendered_cloud_init
}

Template (cloud-init.tpl):

#cloud-config
users:
  - name: ${username}
    groups: sudo
    shell: /bin/bash
    sudo: ["ALL=(ALL) NOPASSWD:ALL"]

runcmd:
  - printf "%s\n" "${motd}" > /etc/motd

This works well for:

Per-environment cloud-init (dev vs staging vs CI).
Injecting SSH keys, user accounts, packages, and systemd unit files.
Staying purely declarative (no provisioners required).

File upload and download without provisioners

Instead of relying on local-exec + multipass transfer, the provider exposes dedicated resources:

multipass_file_upload: host → instance.
multipass_file_download: instance → host.

Example: upload a rendered config and fetch logs back:

resource "multipass_file_upload" "nginx_conf" {
  instance  = multipass_instance.dev.name
  direction = "upload"

  source_path      = "${path.module}/nginx.conf"
  destination_path = "/etc/nginx/nginx.conf"
}

resource "multipass_file_download" "logs" {
  instance  = multipass_instance.dev.name
  direction = "download"

  source_path      = "/var/log/nginx"
  destination_path = "${path.module}/nginx-logs"
}

These resources:

Integrate with Terraform’s dependency graph.
Are idempotent (only rerun when inputs change).
Remove the need for ad-hoc shell provisioners.

Ansible-friendly: stable IPs and inventories

If you’re driving configuration with Ansible (similar to the workflow described in Ryan Schachte’s blog post on Multipass, Terraform & Ansible), you can:

Use networks { mac = "…" } + cloud-init Netplan to get stable IPs.
Expose those IPs via outputs or data sources.
Generate inventory files using local_file or other Terraform tooling.

Example of an inventory-like output:

output "ansible_hosts" {
  value = {
    master  = multipass_instance.lab_master.ipv4[0]
    worker1 = multipass_instance.lab_worker1.ipv4[0]
    worker2 = multipass_instance.lab_worker2.ipv4[0]
  }
}

From there, you can either:

Point Ansible directly at those outputs (e.g. via terraform output -json), or
Render an INI inventory file with local_file and templatefile.

Where to go next

Examples: explore the examples directory (basic, dev-lab, bridged-workstation, cloud-init-lab) for ready-made scenarios.
Docs: check the multipass_instance resource docs for full argument and attribute references, including cloud_init, networks, and mounts.
CI / CD: plug this provider into your existing Terraform flows to bootstrap ephemeral CI runners, dev boxes, or disposable labs on top of Multipass.

With multiple NICs, static IPs via cloud-init, file transfer resources, and inline cloud-init all first-class, this provider is designed to make Multipass feel like a natural part of your Terraform-based infrastructure story.