Terraform Provider

The DoiT Cloud Intelligence Terraform provider lets you manage DoiT Cloud Intelligence™ via code.

Using the DoiT Cloud Intelligence Terraform Provider

The DoiT Cloud Intelligence Terraform provider lets you manage DoiT Cloud Intelligence™ resources via code and integrate cloud cost and operations workflows into your existing Terraform stacks.

The canonical reference for this provider lives on the Terraform Registry. This guide focuses on how to consume the provider inside your own Terraform projects and how it fits into a typical workflow.


When to use this provider

Use the DoiT provider when you want to:

  • Automate the configuration of DoiT Cloud Intelligence resources to eliminate manual management in the UI.
  • Keep DoiT configuration in version control alongside the rest of your infrastructure as code.
  • Standardise how teams onboard onto DoiT services through reusable Terraform modules.
  • Integrate DoiT actions into CI or GitOps-style workflows.

Prerequisites

Before you start, you should have:

  • A DoiT Cloud Intelligence account with API access.

  • Terraform CLI version 1.0 or newer installed locally or in your CI runners.

  • Access to the DoiT Terraform provider on the Registry:

    • source = "doitintl/doit"

Installing the provider

Add the provider to your Terraform configuration in the terraform block:

terraform {
  required_version = ">= 1.0"

  required_providers {
    doit = {
      source  = "doitintl/doit"
      version = "~> 0.26"
    }
  }
}

Notes:

  • source must be doitintl/doit in order to use the provider from the Terraform Registry.
  • The version constraint above targets 0.26.x line as of the latest release. Check the Registry page for the current recommended version and adjust as needed.

After adding this block, run:

terraform init

Terraform will download the DoiT provider from the Registry and install it into your project.


Authentication and configuration

The provider requires authentication with the DoiT API. The exact configuration arguments and supported environment variables are documented in the Terraform Registry Authentication section:

Always refer to https://registry.terraform.io/providers/doitintl/doit/latest/docs

A typical pattern is to:

  1. Generate an API token in your DoiT Cloud Intelligence account.
  2. Store that token in a secure location, for example a CI secret store or a local environment variable.
  3. Wire it into the provider configuration.

Example pattern:

provider "doit" {
  # Example only; use the exact argument names documented in the provider docs
  api_token = var.doit_api_token
}

And in variables.tf:

variable "doit_api_token" {
  type        = string
  description = "DoiT API token used by the Terraform provider"
  sensitive   = true
}

You can then pass the token from the environment or your CI system:

export TF_VAR_doit_api_token="YOUR_TOKEN_VALUE"
terraform plan

Check the provider docs for:

  • Supported authentication methods.
  • Supported environment variables.
  • Any optional arguments such as custom endpoints or timeouts.

📘

Optional

  • api_token (String, Sensitive) API Token to access DoiT API. May also be provided by DOIT_API_TOKEN environment variable. Refer to https://developer.doit.com/docs/start
  • customer_context (String) Customer context. May also be provided by DOIT_CUSTOMER_CONTEXT environment variable. This field is requiered just for DoiT employees
  • host (String) URI for DoiT API. May also be provided via DOIT_HOST environment variable.

Managing the API token with SOPS

For teams already using Git for Terraform, a good pattern is to keep the DoiT API token in an encrypted file managed by SOPS. This allows you to:

  • Keep the Terraform code and secrets in the same repository.
  • Encrypt the secrets file with KMS, GCP KMS, or age so the repo is safe to share.
  • Decrypt secrets only on trusted machines or CI runners with the right keys.

For more information about SOPS, please visit this link.

Basic usage workflow

A minimal Terraform workflow looks like this:

  1. Define the provider (see sections above).
  2. Define one or more DoiT resources or data sources.
  3. Run plan and apply to synchronise state with DoiT Cloud Intelligence.

Because the list of resources changes over time, always start from the list in the Registry:

  • Resources: https://registry.terraform.io/providers/doitintl/doit/latest/docs/resources
  • Data sources: https://registry.terraform.io/providers/doitintl/doit/latest/docs/data-sources

Example structure using a placeholder resource:

terraform {
  required_version = ">= 1.0"

  required_providers {
    doit = {
      source  = "doitintl/doit"
      version = "~> 0.26"
    }
  }
}

provider "doit" {
  # See provider docs for real arguments
  api_token = var.doit_api_token
}

# Replace doit_example_resource with an actual resource from the Registry docs
resource "doit_example_resource" "sample" {
  # Arguments documented at:
  # https://registry.terraform.io/providers/doitintl/doit/latest/docs/resources
}

Run:

terraform init
terraform plan
terraform apply

Managing multiple DoiT accounts or contexts

If you operate more than one DoiT account or need separate configurations (for example different tokens, regions, or endpoints), you can use provider aliases.

Example:

provider "doit" {
  alias     = "prod"
  api_token = var.doit_prod_api_token
}

provider "doit" {
  alias     = "sandbox"
  api_token = var.doit_sandbox_api_token
}

# Use the prod provider for production DoiT resources
resource "doit_example_resource" "prod" {
  provider = doit.prod
  # prod specific arguments
}

# Use the sandbox provider for test resources
resource "doit_example_resource" "sandbox" {
  provider = doit.sandbox
  # sandbox specific arguments
}

This is standard Terraform behaviour and works with any provider, including DoiT.


Composing reusable modules

To standardise DoiT usage across teams, wrap provider usage and resources into internal modules. For example:

modules/doit_project/main.tf:

variable "name" {
  type = string
}

# Example only; replace with a real resource
resource "doit_example_resource" "project" {
  name = var.name
}

output "id" {
  value = doit_example_resource.project.id
}

And consume it:

module "analytics_project" {
  source = "./modules/doit_project"
  name   = "analytics"
}

Benefits:

  • Teams do not have to learn every detail of the provider.
  • You can enforce naming, tagging, or other conventions in one place.
  • Changes to DoiT resource configuration can be rolled out centrally.

Versioning and upgrade strategy

Provider versions evolve over time, adding new resources and possibly changing existing schemas. Recommended practices:

  • Pin a version range in required_providers instead of leaving it unconstrained.

  • When upgrading, update the version range then run:

    terraform init -upgrade
    terraform plan
  • Read the provider changelog and Registry release notes for breaking changes and migration hints.

You can find releases and the changelog in the GitHub repository: https://github.com/doitintl/terraform-provider-doit


Security and secrets handling

Some general guidelines when using the DoiT provider:

  • Treat API tokens and any other DoiT credentials as sensitive and never commit them to git.
  • Use environment variables or your CI secret manager to pass credentials to Terraform.
  • Mark variables that carry secrets as sensitive = true so they do not appear in Terraform logs or plans.
  • Limit token scope and lifetime according to your internal security policy.

For the exact authentication model and recommended environment variables, follow the dedicated Authentication section on the Terraform Registry page.


Troubleshooting

If you encounter issues:

  1. Check the Registry docs first Many common questions about arguments, limits, and resource behaviours are covered there: https://registry.terraform.io/providers/doitintl/doit/latest/docs

  2. Increase Terraform logging Temporarily enable debug logging to see provider calls:

    export TF_LOG=DEBUG
    terraform plan

    Remember to turn this off and avoid sharing logs that contain sensitive data.

  3. Verify your token and permissions

    • Confirm that the API token is valid.
    • Confirm that the token has permissions to manage the specific DoiT resources you are targeting.
  4. Check provider and Terraform versions

    • Make sure you are using a supported Terraform version.
    • Make sure the provider version in your config matches the one you intend to use.
  5. Open an issue if needed If you believe you have hit a bug, include:

    • Provider version.
    • Terraform version.
    • A minimal reproducible configuration.
    • Sanitised logs.

    GitHub repository: https://github.com/doitintl/terraform-provider-doit


References

You can split this content into multiple ReadMe.io pages if you want separate sections for “Getting Started,” “Authentication,” “Advanced usage,” and “Troubleshooting.”