Vet a Terraform provider offline

Terraform providers are native executables. Prepare the provider in one microVM, snapshot it, then run validation and planning in a fresh networkless worker. The random provider makes the flow easy to test because planning it does not need cloud credentials.

Run an offline plan

Create a test configuration

main.tf

terraform {
  required_providers {
    random = {
      source  = "hashicorp/random"
      version = "3.7.2"
    }
  }
}

resource "random_pet" "example" {
  prefix = "microsandbox"
}

Download and snapshot the provider

msb run --name terraform-base --replace \
  --memory 768M --root-disk 2G --max-duration 5m \
  --copy-file ./main.tf:/workspace/main.tf \
  --workdir /workspace \
  --entrypoint sh \
  hashicorp/terraform:1.13.5 -- -lc \
    'terraform init -backend=false -input=false && chown -R 65534:65534 /workspace'

msb run --name terraform-base --replace `
  --memory 768M --root-disk 2G --max-duration 5m `
  --copy-file ./main.tf:/workspace/main.tf `
  --workdir /workspace `
  --entrypoint sh `
  hashicorp/terraform:1.13.5 -- -lc `
    'terraform init -backend=false -input=false && chown -R 65534:65534 /workspace'

Copy the generated dependency lock file to the host:

msb cp terraform-base:/workspace/.terraform.lock.hcl ./.terraform.lock.hcl

Capture the downloaded provider:

msb snap create terraform-runtime \
  --sandbox terraform-base --integrity

msb snap create terraform-runtime `
  --sandbox terraform-base --integrity

Verify the snapshot before using it:

msb snap verify terraform-base:terraform-runtime

terraform init downloads the provider and creates .terraform.lock.hcl. The copy on the host is ready to review and commit when adapting this to a real module.

Plan offline

Restore applies the offline policy and restricted guest profile before boot. It creates an idle detached sandbox; exec runs the plan separately. The destination name must be unused, so remove a previous stopped terraform-vet explicitly before repeating this step.

msb snap restore terraform-base:terraform-runtime --name terraform-vet \
  --user 65534:65534 --cpus 1 --memory 512M \
  --no-net --security restricted --max-duration 1m
msb exec --workdir /workspace --user 65534:65534 --env HOME=/tmp \
  --timeout 1m terraform-vet -- sh -lc \
    'terraform fmt -check && terraform validate && terraform plan -refresh=false -input=false -lock=false'
msb stop terraform-vet

msb snap restore terraform-base:terraform-runtime --name terraform-vet `
  --user 65534:65534 --cpus 1 --memory 512M `
  --no-net --security restricted --max-duration 1m
msb exec --workdir /workspace --user 65534:65534 --env HOME=/tmp `
  --timeout 1m terraform-vet -- sh -lc `
    'terraform fmt -check && terraform validate && terraform plan -refresh=false -input=false -lock=false'
msb stop terraform-vet

The provider loads and creates a plan, but it cannot contact any remote API. Providers, data sources, or validation rules that require a service will fail offline; that failure is the point of this vetting mode.

-refresh=false is not a network boundary. --no-net is. If you give a provider credentials and egress, changes it makes through an external API outlive the microVM.

Clean up

msb rm -f terraform-base terraform-vet

Remove the reusable snapshot:

msb snap rm terraform-base:terraform-runtime

Overview

AI Agents

Dev Environments

CI/CD & Jobs

Browser & Web Automation

File Processing

Docker & System Tools

Data & Storage

Observability

Vet a Terraform provider offline

Run an offline plan

Reference

​Run an offline plan

​Reference

Run an offline plan

Reference