Reading Time: 18 minutes

Every new Anypoint environment starts the same way: log into Anypoint Platform, navigate to Access Management, click “Environments,” fill out the form, wait for validation, then repeat for the next business group. Platform teams spend hours each week manually provisioning sandbox and production environments, copying configurations, and ensuring consistency across deployments. What if you could declare your entire Anypoint infrastructure as code and let Terraform handle the rest?

The MuleSoft Anypoint Terraform Provider brings Infrastructure-as-Code (IaC) principles to Anypoint Platform. Currently in Customer Zero validation with MuleSoft engineering teams, the provider allows you to manage environments, flex gateways, API instances, and more through declarative Terraform configurations. This means version-controlled infrastructure, peer-reviewed changes, and automated provisioning workflows—all the benefits of GitOps applied to your integration platform.

In this tutorial, you’ll learn how to use the Anypoint Terraform Provider to create sandbox and production environments in minutes instead of hours.

What is the Anypoint Terraform Provider?

The Anypoint Terraform Provider is a Terraform plugin that translates infrastructure declarations into Anypoint Platform API calls. Instead of clicking through the UI or writing custom scripts, you define your desired state in .tf files, and Terraform orchestrates the creation, updates, and deletion of resources.

Key capabilities

With the Anypoint Terraform Provider, you can:

  • Manage environments across multiple business groups with consistent naming and configuration
  • Provision flex gateways with standardized policies and deployment targets
  • Deploy API instances with policies pre-applied and SLA tiers configured
  • Track infrastructure state in version control, enabling rollback and audit trails
  • Automate provisioning through CI/CD pipelines, reducing manual toil

How it works

At its core, the provider acts as a bridge between Terraform’s declarative syntax and Anypoint Platform’s REST APIs. When you run terraform apply, the provider:

  1. Authenticates with Anypoint Platform using your credentials
  2. Translates resource declarations (e.g., anypoint_environment) into API requests
  3. Creates or updates resources via the Anypoint Platform API
  4. Stores resource metadata (IDs, names, attributes) in Terraform state
  5. Provides output values for use in other configurations or systems

This approach ensures that your Anypoint infrastructure is repeatable, versioned, and auditable—just like application code.

Architecture overview

The provider follows Terraform’s standard plugin architecture:

┌─────────────────────┐
│  Terraform CLI      │
│  (terraform apply)  │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Anypoint Provider   │
│ (resource logic)    │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ Anypoint Platform   │
│ REST APIs           │
└─────────────────────┘

The provider handles authentication, API request construction, error handling, and state management. You focus on declaring what you want; Terraform and the provider figure out how to achieve it.

Tutorial: Provisioning Anypoint Environments With Terraform

In this hands-on tutorial, you’ll use the Anypoint Terraform Provider to create two environments in an Anypoint business group: a sandbox environment for development and a production environment for live integrations.

Prerequisites

Before you begin, ensure you have:

  • Terraform 1.0+ installed (installation guide)
  • MuleSoft Terraform documentation 
  • Anypoint Platform account with Organization Administrator permissions
  • Connected App credentials (client ID, client secret, username, password)
    • Note: The provider currently requires password grant (App1) authentication; client credentials alone will return “username is required”
  • Organization ID for your target business group
  • Basic familiarity with Terraform workflows (init, plan, apply)

Tip: You can find your Organization ID in Anypoint Platform under Access Management > Organization > Business Groups.

Step 1: Create the provider configuration

First, create a new directory for your Terraform project:

mkdir anypoint-terraform-demo
cd anypoint-terraform-demo

Create a main.tf file with the provider configuration:

terraform {
  required_providers {
    anypoint = {
      source  = "sf.com/mulesoft/anypoint"
      version = "0.1.0"
    }
  }
}

# Provider authentication configuration
provider "anypoint" {
  base_url      = var.anypoint_base_url
  client_id     = var.anypoint_admin_client_id
  client_secret = var.anypoint_admin_client_secret
  username      = var.anypoint_admin_username
  password      = var.anypoint_admin_password
}

What this does:

  • Declares the Anypoint provider with version 0.1.0 (Customer Zero release)
  • Configures authentication using variables (values defined in the next step)
  • Sets the base_url to support both production and staging Anypoint environments

Step 2: Define variables for credentials

Create a variables.tf file to externalize configuration values:

variable "anypoint_base_url" {
  description = "Anypoint Platform base URL"
  type        = string
  default     = "https://anypoint.mulesoft.com"
}

variable "organization_id" {
  description = "Organization ID (Business Group)"
  type        = string
}

variable "anypoint_admin_client_id" {
  description = "Connected App client ID (password grant)"
  type        = string
}

variable "anypoint_admin_client_secret" {
  description = "Connected App client secret"
  type        = string
  sensitive   = true
}

variable "anypoint_admin_username" {
  description = "Anypoint admin username"
  type        = string
}

variable "anypoint_admin_password" {
  description = "Anypoint admin password"
  type        = string
  sensitive   = true
}

variable "sandbox_name" {
  description = "Name of the sandbox environment"
  type        = string
  default     = "dev-sandbox"
}

variable "production_name" {
  description = "Name of the production environment"
  type        = string
  default     = "prod"
}

Security note: Mark client_secret and password as sensitive = true to prevent Terraform from displaying these values in logs or console output in terminal.

Step 3: Create a terraform.tfvars file

Create aterraform.tfvars file with your actual credentials (this file should be .gitignore’d):

organization_id               = "<YOUR_ORG_ID>"
anypoint_admin_client_id      = "<YOUR_CLIENT_ID>"
anypoint_admin_client_secret  = "***REDACTED***"
anypoint_admin_username       = "<YOUR_USERNAME>"
anypoint_admin_password       = "***REDACTED***"
sandbox_name                  = "dev-sandbox"
production_name               = "prod"

⚠️ Important: Never commit terraform.tfvars to version control. Add it to .gitignore:

echo "terraform.tfvars" >> .gitignore
echo ".terraform/" >> .gitignore
echo "*.tfstate*" >> .gitignore

Step 4: Define environment resources

Add environment resource declarations to main.tf:

resource "anypoint_environment" "sandbox" {
  organization_id = var.organization_id
  name            = var.sandbox_name
  type            = "sandbox"
  is_production   = false
}

resource "anypoint_environment" "production" {
  organization_id = var.organization_id
  name            = var.production_name
  type            = "production"
  is_production   = true
}

What this does:

  • Declares two anypoint_environment resources: one sandbox, one production
  • Sets type to match the environment’s purpose (sandbox or production)
  • Sets is_production to control production-level restrictions (e.g., deployment policies)

Note: The type field determines how the environment appears in Anypoint Platform, while is_production controls platform-level governance features.

Step 5: Define outputs

Add an outputs.tf file to expose environment IDs and names:

output "sandbox_id" {
  description = "ID of the sandbox environment"
  value       = anypoint_environment.sandbox.id
}

output "sandbox_name" {
  description = "Name of the sandbox environment"
  value       = anypoint_environment.sandbox.name
}

output "production_id" {
  description = "ID of the production environment"
  value       = anypoint_environment.production.id
}

output "production_name" {
  description = "Name of the production environment"
  value       = anypoint_environment.production.name
}

These outputs can be referenced by other Terraform configurations or CI/CD pipelines (e.g., to deploy Mule applications to the newly created environments).

Step 6: Initialize Terraform

Run terraform init to download the Anypoint provider plugin:

terraform init

Expected output:

Initializing the backend...

Initializing provider plugins...
- Finding sf.com/mulesoft/anypoint versions matching "0.1.0"...
- Installing sf.com/mulesoft/anypoint v0.1.0...
- Installed sf.com/mulesoft/anypoint v0.1.0

Terraform has been successfully initialized!

Step 7: Preview the changes with terraform plan

Run terraform plan to see what Terraform will create:

terraform plan

Expected output:

Terraform will perform the following actions:

  # anypoint_environment.production will be created
  + resource "anypoint_environment" "production" {
      + id              = (known after apply)
      + name            = "prod"
      + organization_id = "b1c4565e-c3e5-4272-b931-c51151dabad6"
      + type            = "production"
      + is_production   = true
    }

  # anypoint_environment.sandbox will be created
  + resource "anypoint_environment" "sandbox" {
      + id              = (known after apply)
      + name            = "dev-sandbox"
      + organization_id = "b1c4565e-c3e5-4272-b931-c51151dabad6"
      + type            = "sandbox"
      + is_production   = false
    }

Plan: 2 to add, 0 to change, 0 to destroy.

This preview shows that Terraform will create two new environments. The id field will be populated after creation.

Step 8: Apply the configuration

Run terraform apply to create the environments:

terraform apply

Terraform will prompt for confirmation:

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

Type yes and press Enter.

Expected output:

anypoint_environment.sandbox: Creating...
anypoint_environment.production: Creating...
anypoint_environment.sandbox: Creation complete after 3s [id=9919e264-2e6d-40a0-bc25-d53a3d53e28b]
anypoint_environment.production: Creation complete after 3s [id=e087da0c-a77c-45f9-9b5f-0b5e54464949]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Outputs:

sandbox_id      = "9919e264-2e6d-40a0-bc25-d53a3d53e28b"
sandbox_name    = "dev-sandbox"
production_id   = "e087da0c-a77c-45f9-9b5f-0b5e54464949"
production_name = "prod"

In about 5 seconds, Terraform created both environments. What used to require multiple UI workflows now happens with a single command.

Step 9: Verify the environments in Anypoint Platform

Now, verify that the environments were created correctly:

Method 1: Anypoint Platform UI

  1. Log into Anypoint Platform
  2. Navigate to Access Management > Environments
  3. You should see both dev-sandbox and prod environments listed

Note: You may see additional default environments (Design, Sandbox) that exist in every organization. Focus on the two you just created: dev-sandbox and prod.

Method 2: Terraform state inspection

Run terraform show to inspect the current state:

terraform show

This displays the full state of all managed resources, including their IDs, names, and attributes.

Method 3: Anypoint CLI (optional)

If you have the Anypoint CLI installed, you can verify via command line:

anypoint-cli-v4 environment list --organizationId=<YOUR_ORG_ID>

You should see both environments in the output.

Step 10: Test infrastructure immutability with terraform plan

Run terraform plan again (without making any changes):

terraform plan

Expected output:

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

This confirms that your Terraform state matches the actual state in Anypoint Platform. If someone manually changed an environment name in the UI, Terraform would detect the drift and offer to correct it.

Updating infrastructure: Renaming an environment

Let’s demonstrate in-place updates by renaming the sandbox environment.

Edit terraform.tfvars and change the sandbox_name:

sandbox_name = "dev-sandbox-v2"

Run terraform plan:

terraform plan

Expected output:

Terraform will perform the following actions:

  # anypoint_environment.sandbox will be updated in-place
  ~ resource "anypoint_environment" "sandbox" {
        id              = "9919e264-2e6d-40a0-bc25-d53a3d53e28b"
      ~ name            = "dev-sandbox" -> "dev-sandbox-v2"
        # (3 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Notice the ~ symbol indicating an in-place update. The provider will send a PATCH request to rename the environment without destroying and recreating it.

Run terraform apply:

terraform apply

Expected output:

anypoint_environment.sandbox: Modifying... [id=9919e264-2e6d-40a0-bc25-d53a3d53e28b]
anypoint_environment.sandbox: Modifications complete after 2s [id=9919e264-2e6d-40a0-bc25-d53a3d53e28b]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

The environment was renamed in 2 seconds, and the resource ID remained unchanged. No downtime, no manual intervention.

Cleaning up: Destroying resources

When you’re done with the tutorial, clean up the resources:

terraform destroy

Terraform will prompt for confirmation:

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

Type yes and press Enter.

Expected output:

anypoint_environment.sandbox: Destroying... [id=9919e264-2e6d-40a0-bc25-d53a3d53e28b]
anypoint_environment.production: Destroying... [id=e087da0c-a77c-45f9-9b5f-0b5e54464949]
anypoint_environment.sandbox: Destruction complete after 4s
anypoint_environment.production: Destruction complete after 4s

Destroy complete! Resources: 2 destroyed.

Both environments are deleted from Anypoint Platform, and the Terraform state is cleared.

Infrastructure-as-Code for Anypoint Platform

By treating your Anypoint infrastructure as code, you unlock version control, peer review, and automated provisioning workflows. What used to take hours of manual clicking now happens in seconds with terraform apply. Your platform team can provision consistent environments across business groups, track changes in Git, and enforce standards through automated pipelines.

This tutorial covered the basics: creating, updating, and destroying environments. The Anypoint Terraform Provider also supports Omni gateways, API / MCP / Agents instances, policies, and more—enabling end-to-end automation of your Anypoint Platform infrastructure.

Ready to get started?