YugabyteDB Anywhere has a Terraform provider that can manage YBA resources and configuration as Infrastructure as Code.
The v1.1.0 development track takes that a step further.
On September 15, 2026, v1.1.0-alpha.1 of the YugabyteDB Anywhere Terraform Provider was published as a pre-release. Because it is an alpha build, Terraform will not select it automatically when using a normal stable version constraint… you need to explicitly pin the version if you want to test it. The GitHub release is also explicitly marked as a pre-release.
💡 Why this matters
The provider already manages core YBA entities such as cloud providers, universes, storage configurations, backups, restores, and YBA installation. The v1.0 release also introduced typed cloud-provider and storage resources, replacing several older generic resources.
The v1.1.0-alpha.1 release adds several more pieces needed to move toward a “YBA as Code” model.
What’s New?
The release changelog specifically includes the load-balancer implementation, telemetry configuration, Performance Advisor resources, runtime configuration, certificate and certificate-rotation support, pre-release YBA version support, and inline-content support for yba_installer.
Why “Zero Click-Ops” Is Important
Terraform is most useful when the desired state of the environment lives in source-controlled configuration.
For example, imagine deploying a new YBA environment and then having to manually:
- ● Enable runtime configuration flags.
- ● Configure telemetry.
- ● Set load-balancer options.
- ● Register Performance Advisor components.
- ● Configure certificates.
- ● Adjust installer configuration.
The infrastructure may technically have been deployed by Terraform, but part of the environment still exists only as a sequence of manual steps.
That creates several problems:
- ● The environment becomes harder to reproduce.
- ● A disaster-recovery environment may not be configured exactly like production.
- ● A new development or test environment may be missing one small but important setting.
- ● Months later, nobody may remember why a particular YBA setting was enabled.
A Small Demo: Manage a YBA Runtime Configuration with Terraform
One of the additions I particularly like is the new yba_runtime_config resource.
YBA has a hierarchical runtime-configuration system, and the new Terraform resource lets a configuration key and value become part of the Terraform state.
The provider documentation notes that the resource can manage global runtime configuration by default, or a specific scope can be supplied. Removing the Terraform resource causes the override to be removed through the YBA API.
For this demo, let’s enable the runtime configuration that allows universe metrics export.
Step 1: Pin the Alpha Provider
Because v1.1.0-alpha.1 is a pre-release, explicitly pin it:
terraform {
required_providers {
yba = {
source = "yugabyte/yba"
version = "1.1.0-alpha.1"
}
}
}
alpha.1 suffix is intentional. Pin the exact version when testing it rather than using a broad version constraint. Step 2: Configure the YBA Provider
The provider can read its connection information from environment variables.
For example:
export YBA_HOST="yba.example.com"
export YBA_API_TOKEN="your-api-token"
export YBA_ENABLE_HTTPS=true
Then the Terraform provider block can stay simple:
provider "yba" {}
The provider prefers the YBA_HOST, YBA_API_TOKEN, and YBA_ENABLE_HTTPS environment variables for new configurations.
YBA_API_TOKEN avoids hard-coding the API token directly into the Terraform configuration. Step 3: Add a Runtime Configuration
Create a file such as runtime-config.tf:
resource "yba_runtime_config" "metrics_export_enabled" {
key = "yb.universe.metrics_export_enabled"
value = "true"
}
The global scope is used by default, so the all-zero global UUID does not need to be specified explicitly.
The provider documentation uses this exact runtime key as an example for enabling per-universe metrics export. Runtime configuration values are represented as strings and validated by YBA against the type of the underlying setting.
Step 4: Initialize Terraform
terraform init -upgrade
Terraform should install the explicitly pinned provider:
- Installing yugabyte/yba v1.1.0-alpha.1...
- Installed yugabyte/yba v1.1.0-alpha.1
Step 5: Review the Plan
terraform plan
You should see Terraform propose creation of the runtime configuration:
# yba_runtime_config.metrics_export_enabled will be created
+ resource "yba_runtime_config" "metrics_export_enabled" {
+ key = "yb.universe.metrics_export_enabled"
+ value = "true"
}
Plan: 1 to add, 0 to change, 0 to destroy.
Step 6: Apply It
terraform apply
After reviewing the plan:
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
Now that YBA setting is no longer an undocumented manual step.
It is part of the Terraform configuration.
Scope Runtime Configuration When Needed
Runtime configuration is hierarchical in YBA.
The Terraform resource supports a scope UUID when you do not want the setting applied globally. The resource documentation states that the global scope is the default.
For example:
resource "yba_runtime_config" "universe_setting" {
scope = var.universe_uuid
key = "some.universe.runtime.key"
value = "true"
}
That makes it possible to manage global, universe-specific, provider-specific, or other supported scoped configuration without turning the settings into click-ops.
Terraform Also Helps Expose Configuration Drift
There is another benefit to managing more YBA configuration through Terraform: drift becomes visible.
If somebody changes a Terraform-managed setting directly in the YBA UI or through the API, a subsequent terraform plan can show that the live YBA state differs from the desired configuration.
The provider documentation specifically recommends reviewing terraform plan before applying changes and warns against blindly using terraform apply -auto-approve when UI/API changes may exist.
For automated pipelines, the documentation also suggests using:
terraform plan -detailed-exitcode -out=tfplan
where:
0 = no changes
1 = error
2 = changes detected
A pipeline can use exit code 2 to require review before applying a change.
That can turn Terraform into a useful configuration-drift detector in addition to a provisioning tool.
What About v1.0.0?
The previous v1.0.0 release was a significant milestone itself.
It introduced typed AWS, GCP, and Azure provider resources, typed storage configuration resources, on-demand backups, improved universe lifecycle operations, and several migration improvements from the older v0.1.x resource model.
The v1.1.0 development work builds on that foundation by moving additional YBA configuration into Terraform.
That progression is important:
The closer all of those steps get to declarative configuration, the easier the entire YBA environment becomes to reproduce.
A Few Things to Keep in Mind
The Terraform provider documentation currently describes the provider as Early Access and states that Kubernetes universes are not currently supported. It also lists YBA stable 2024.2.0.0 or later, or preview 2.23.1.0 or later, as the minimum supported YBA versions.
And v1.1.0-alpha.1 is specifically a pre-release… not the final v1.1.0.
That makes this a great release to experiment with in a lab or development environment and to start identifying which remaining YBA configuration steps can be moved out of runbooks and into Terraform.
Final Takeaway
v1.1.0-alpha.1 is not any single new Terraform resource. It is the direction the provider is moving.Have Fun!
After touring the George W. Bush Presidential Museum in Dallas during our QBR last week, we wrapped up the visit with a delicious sit-down dinner at the President’s Club. 🇺🇸🍽️
The food was fantastic, especially the hors d’oeuvres! The only problem was the fish course. 😂 Luckily, my Account Executive loves seafood, while I absolutely despise it, so he was more than happy to take mine off my hands. Win-win! 🐟➡️😄