Manage Bronto with Terraform

Use the official Bronto Terraform provider to manage resources, import existing configuration, and automate changes.

The official Bronto Terraform provider lets you version, review, and deploy Bronto configuration alongside the rest of your infrastructure.

Use this guide to configure the provider, export existing Bronto resources, and manage your first resource as code. For every available argument and exported attribute, use the Terraform Registry reference below.

Terraform Registry

Browse the generated provider, resource, and data source reference.

GitHub repository

View the provider source, examples, and release history.

Use the latest provider release. The examples on this page require v0.4.0 or later; run terraform init -upgrade to update the version selected in your dependency lock file.

​

What you can manage

The provider supports these Bronto resources:

Resource	Use it to
bronto_user	Create and manage Bronto users and their roles
bronto_dashboard	Create and manage dashboards
bronto_widget	Define dashboard widgets
bronto_metric_definition	Create saved metric definitions
bronto_monitor	Create monitors that evaluate metric definitions and send notifications
bronto_slack_integration	Configure Slack notification integrations
bronto_webhook_integration	Configure webhook notification integrations

The provider also includes these data sources:

Data source	Use it to
bronto_dataset	Look up a dataset by ID or by its collection and dataset name
bronto_slack_workspaces	List Slack workspaces already connected to the organisation
bronto_user	Look up an existing user by ID or email

​

Prerequisites

Before you begin, you need:

• Terraform 1.5 or later
• A Bronto API endpoint, such as https://api.eu.bronto.io
• A Bronto API key with write permission for the resources you want to manage

For an initial evaluation of the full provider, use an Admin API key. For ongoing use, create a dedicated key with only the permissions required by your configuration. See API Keys for instructions.

​

Configure the provider

1. Declare the provider

   Create a Terraform configuration that uses the latest provider release. The minimum version below includes monitor support:

   main.tf

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       bronto = {
         source  = "brontoio/bronto"
         version = ">= 0.4.0"
       }
     }
   }
   
   variable "bronto_endpoint" {
     description = "Base URL for the Bronto API"
     type        = string
     default     = "https://api.eu.bronto.io"
   }
   
   variable "bronto_api_key" {
     description = "API key used to manage Bronto resources"
     type        = string
     sensitive   = true
   }
   
   provider "bronto" {
     endpoint = var.bronto_endpoint
     api_key  = var.bronto_api_key
   
     default_tags = {
       managed_by = "terraform"
     }
   }
   

   Change bronto_endpoint if your organisation uses another Bronto region or environment. default_tags are merged into every taggable bronto_user, bronto_dashboard, and bronto_widget; tags set directly on a resource take precedence.

2. Provide the API key securely

   Pass the API key through an environment variable rather than writing it into a committed .tf or .tfvars file:

   export TF_VAR_bronto_api_key="<YOUR_API_KEY>"
   

   The provider also supports the BRONTO_ENDPOINT and BRONTO_API_KEY environment variables. In CI, inject credentials from your platform’s secret store.

3. Declare a Bronto resource

   Add a user resource to the configuration:

   main.tf

   resource "bronto_user" "example" {
     first_name = "Jane"
     last_name  = "Doe"
     email      = "[e-mail]"
     roles      = ["Standard"]
   }
   

   Applying this example creates a real Bronto user and may send an invitation email. Replace the example address with an address you control.

4. Review and apply the change

   Initialise Terraform, validate the configuration, and review the plan before applying it:

   terraform init
   terraform fmt
   terraform validate
   terraform plan
   terraform apply
   

   Commit the generated .terraform.lock.hcl file so every environment uses the same provider build.

​

Export existing resources from Bronto

Bronto can generate HCL for existing dashboards, monitors, users, Slack integrations, and webhook integrations. This gives you a starting configuration and an import block that adopts the existing object instead of creating a duplicate. Dashboard exports also include their widgets.

The Bronto UI labels the format Terraform (HCL) and the download action Download Terraform. The generated .tf file is also compatible with OpenTofu.

1. Open the resource menu

   In Bronto, find the dashboard, monitor, user, Slack integration, or webhook you want to manage as code. Open its actions menu and select Export.

2. Review the generated HCL

   The export panel shows the resource block and its matching import block. For a dashboard, the export includes its widgets. Enable Include referenced metrics when you also want the referenced metric definitions in the generated file.

3. Copy or download the configuration

   Select Copy to copy the HCL, or Download Terraform to download it as a .tf file. Add the configuration to your existing Terraform project.

4. Plan the import

   Run terraform plan and inspect the proposed import and resource state before applying it. The import adopts the existing Bronto resource; it does not create another one.

​

Manage multiple organisations

Declare an aliased provider for each organisation when a root organisation and its child organisations use different API keys. Then select the correct provider on every resource. Users belong to the root organisation, so manage bronto_user resources with the root provider.

main.tf

provider "bronto" {
  alias    = "root"
  endpoint = var.bronto_endpoint
  api_key  = var.root_org_api_key
}

provider "bronto" {
  alias    = "child"
  endpoint = var.bronto_endpoint
  api_key  = var.child_org_api_key
}

resource "bronto_user" "root_user" {
  provider = bronto.root

  first_name = "Jane"
  last_name  = "Doe"
  email      = "[e-mail]"
  roles      = ["Standard"]
}

resource "bronto_dashboard" "child_dashboard" {
  provider = bronto.child

  name = "Child organisation overview"
}

Use a separate API key for each organisation and store every key independently. For more information about the organisation model, see Multi-Organisation.

​

Recommended workflow

• Run terraform fmt and terraform validate on every change.
• Run terraform plan in pull requests and require review before applying.
• Run terraform init -upgrade, then review and commit the updated .terraform.lock.hcl, when adopting a newer provider release.
• Use separate state and API keys for development, staging, and production.
• Avoid editing an IaC-managed resource in both the Bronto UI and your HCL configuration, because the next apply can replace the manual change.
• Review a destroy plan carefully. Removing a resource from configuration can delete the corresponding resource in Bronto.
• Refer to the Terraform Registry for current schemas and examples instead of copying schema details into your own documentation.

​

Troubleshooting

​

Authentication fails

Confirm that the API key is active and has permission to read and write every resource in the configuration. Check that the key and endpoint belong to the same Bronto region and organisation.

​

Terraform manages the wrong organisation

When you use provider aliases, add provider = bronto.<alias> to each resource. Terraform otherwise uses the default, unaliased provider configuration.

​

A plan shows unexpected changes

Check whether the resource was changed in the Bronto UI after the last apply. Review the generated plan before reconciling the configuration or applying the change.