Databricks Terraform provider: running a workspace as code

The provider covers the whole workspace surface

The Databricks Terraform provider is registered in the Terraform registry under the `databricks` namespace, and its source is the `databricks/databricks` provider. The documentation states that it works with Terraform 1.1.5 or newer.

What it manages is visible in the repository layout, where each top level directory is a product area of the platform: `clusters`, `jobs`, `pipelines`, `mlflow`, `catalog`, `serving`, `apps`, `permissions`, `policies`, `pools`, `repos`, `scim`, `secrets`, `sharing`, `access`, `aws`, `finops`, `settings`, `commands`, `mws` and `exporter`, alongside shared plumbing in `common`, `internal`, `logger`, `docs` and `qa`.

That spread is the real answer to whether the provider is enough for a workspace. Jobs and clusters are the obvious core, and the presence of `catalog`, `serving` and `mlflow` means Unity Catalog objects, model serving endpoints and experiment tracking are all declarable, while `mws` and `aws` cover the account level on AWS. The repository also carries a `scripts` directory, a `Makefile` and a `godownloader-databricks-provider.sh`, plus `AGENTS.md` and `CLAUDE.md` files that describe how the project expects code to be written.

A provider block with a host and a personal access token

The quick start in the repository readme begins with the standard required_providers block:

terraform {
  required_providers {
    databricks = {
      source = "databricks/databricks"
    }
  }
}

The provider itself is configured with a workspace host and a token. The token is a PAT, a personal access token created from the Databricks documentation on API authentication, and the readme asks you to replace the placeholder with your own:

provider "databricks" {
  host  = "https://abc-defg-024.cloud.databricks.com/"
  token = "<your PAT token>"
}

data "databricks_current_user" "me" {}
data "databricks_spark_version" "latest" {}
data "databricks_node_type" "smallest" {
  local_disk = true
}

After the configuration file, you run `terraform init` and then `terraform apply` to apply the HCL to your workspace. The readme also points at the registry page for the official instructions and at the contributing guidelines if you want to build the provider from source.

Data sources do the discovery so resources can be small

The sample configuration is more instructive than it first appears, because most of it is about not hardcoding values.

Three data sources do the discovery. `databricks_current_user` returns the identity and the home path of the caller. `databricks_spark_version` returns the latest available Spark version as an id. `databricks_node_type` looks up a node type, and the sample filters it with `local_disk = true` to pick a small instance with local disk rather than pinning a cloud-specific node id that would not exist on another cloud.

The resources then consume those data sources rather than literal strings. The notebook resource builds its path from the current user's home, so it lands in the right place on any workspace without editing the configuration. The job resource names itself after the current user's alphanumeric identifier, so repeated applies in one account do not collide, and its `new_cluster` block pulls the Spark version and node type from the data sources.

The output blocks at the end publish the notebook URL and the job URL, which is the pattern to follow when you want the apply to hand back something a human can click. A complete working example of this shape is what the end-to-end workspace management tutorial in the `docs/guides` directory covers, alongside separate AWS and Azure workspace tutorials.

The namespace move still catches people out

The provider used to live under the `databrickslabs` namespace and now lives under `databricks`, moved so it could be made generally available in the registry. The documentation is explicit that existing deployments keep working without any action, but asks you to replace `databrickslabs/databricks` with `databricks/databricks` in all your `.tf` files.

The symptom of not doing it is a warning during `terraform init`:

Warning: Additional provider information from registry

The remote registry returned warnings for registry.terraform.io/databrickslabs/databricks:
- For users on Terraform 0.13 or greater, this provider has moved to databricks/databricks. Please update your source in required_providers.

The documented fix is a global search and replace across `*.tf` files, or running the command `python3 -c "$(curl -Ls https://dbricks.co/updtfns)"` from the command line, which the documentation says does the tedious work for you. That helper fetches and runs a script from a short link, which is worth thinking about before you paste it into a production pipeline.

There is a second trap that catches people. You should have a `.terraform.lock.hcl` file in your state directory checked into source control. Without it, you may hit a `Failed to install provider` error, and the troubleshooting guide in `docs/guides` has the steps for resolving that.

Well-known types decide how you write durations and timestamps

The provider normalises some field types so the same configuration works across resources, and the readme documents three of them.

Duration fields accept Go-style duration strings using standard units such as `s`, `m` and `h`:

resource "databricks_example" "this" {
  timeout_duration = "30m"   # 30 minutes
  retry_delay      = "10s"   # 10 seconds
  max_lifetime     = "24h"   # 24 hours
  short_timeout    = "500ms" # 500 milliseconds
}

Timestamp fields require RFC3339 formatted datetime strings, and the documentation asks you to include timezone information for the best results:

resource "databricks_example" "this" {
  start_time = "2023-10-15T14:30:00Z"      # UTC timezone
  end_time   = "2023-10-15T14:30:00-07:00" # Pacific timezone
  created_at = "2023-10-15T14:30:00.123Z"  # With milliseconds
}

JSON value fields accept JSON-encoded strings, and the provider will normalise and validate the JSON structure, which is usually written with the `jsonencode` function:

resource "databricks_example" "this" {
  settings = jsonencode({
    enabled = true
    options = ["option1", "option2"]
  })
}

The `databricks_example` resource name in these samples is a placeholder for any resource that has those fields. The point of documenting them centrally is that a duration written as `"30m"` behaves the same whether it lands in a cluster timeout or a job retry policy.

OpenTofu is untested and the exporter may change

Two limitations are stated plainly and they deserve to shape your decision.

The first is OpenTofu. OpenTofu is an open source fork of Terraform with the MPL 2.0 licence, and the documentation says the Databricks Terraform provider should be compatible with it, but the integration is not actively tested and should be considered experimental. The instruction to users is to raise a GitHub issue if they hit an incompatibility. That is a clear statement of risk: if your organisation standardised on OpenTofu, you are running an unverified path and you are the tester.

The second is the Terraform exporter, the functionality that imports an existing workspace into configuration. It is described as experimental and provided as is, with an evolving interface that may change or be removed in future versions of the provider. For a team migrating a hand-built workspace to code, that is a real risk to plan around, because the import you run today may not survive the next provider release.

A third, smaller one is the PAT token in the provider block. The documented authentication route is a personal access token, so your CI needs a way to inject it, and the repository carries an `.env.template` and a `.devcontainer` directory for local work.

Custom licence terms and a weekly release line

The licence is recorded as a custom one that GitHub cannot classify, so the terms live in the `LICENSE` file at the root, and the repository also carries a `NOTICE` file. This is the arrangement used by many vendor providers: the code is available for reading, and the terms sit in files rather than in a standard SPDX identifier, so read both before you build redistribution or contribution terms around it.

The Go module tells you what the provider is built on. It requires Go 1.26.8, the Databricks SDK for Go at v0.185.0, and both Terraform plugin frameworks at once: `terraform-plugin-framework` v1.18.0 alongside `terraform-plugin-sdk/v2` v2.39.0, with `terraform-plugin-mux` to serve them together. That combination is the reason the provider can expose newer resources on the plugin framework while keeping older ones on the legacy SDK. It also uses `terraform-plugin-framework-jsontypes` and `terraform-plugin-framework-timetypes`, which are the framework packages behind the well-known types described earlier.

On cadence the provider moves quickly. Version 1.136.0 was tagged on 2026-10-05, 1.137.0 on 2026-10-06 and 1.138.0 on 2026-10-19, and the last push was on 2026-10-22. The default branch is `main`, there is a `CHANGELOG.md` and a `NEXT_CHANGELOG.md` in the root, and the build is covered by a GitHub Actions workflow whose badge sits at the top of the readme next to a codecov badge.

Editorial conclusion

The Databricks Terraform provider suits platform teams that want clusters, jobs and permissions for a Databricks workspace declared in version control rather than clicked together in the UI. It is a poor fit for a team that needs its Terraform equivalent to be OpenTofu, since that integration is not actively tested, or for anyone who wants a stable import of an existing workspace, since the exporter may change or disappear. Before adopting it, read the troubleshooting guide about the lock file, decide how you will handle the PAT token in CI, and check the CHANGELOG.md because the provider ships roughly weekly minor versions, with v1.138.0 tagged on 2026-10-19.

Frequently asked questions

Official sources

1. databricks/terraform-provider-databricks on GitHub
2. Issues
3. Project website
4. README
5. Releases