The Juju Terraform provider 1.0.0

announcements and community
1

The Juju Terraform provider 1.0.0 (To be released on 27 October 2025)

Following a long string of 0.x.y releases we are happy to announce an imminent release of the Juju Terraform provider version 1.0.0. As you probably noticed we have established a regular monthly release cadence in the last cycle and this version marks a big step in the development of the Juju Terraform provider as we are moving out of the initial “beta” development.

I would like to take this opportunity to thank the JAAS team for all their efforts, the Juju team for their support, and @massigori for his guidance and prioritization.

Last but not least I would like to give a big shoutout to IS, SolutionsQA and the Identity teams for testing all releases leading up to 1.0.0 and helping us iron out any issues.

Why and What is 1.0.0

Since the 1.0.0 version of the Juju Terraform provider is a major version, it contains fixes and enhancements but also design changes that will require your action.

In the next cycle we will follow the current monthly cadence of minor releases, with new feature development limited to 1.x.y releases.

If you are still using an older version of the Juju Terraform provider and cannot immediately move to 1.0.0, we encourage you to update your plans to use the latest version, 0.23.1, which contains many fixes and quality of life improvements over earlier releases. Version 0.23.1 will still be receiving security fixes for some time (exact timing is still to be determined) and we expect it to be EOL before April 2026.

Thus, we strongly advise starting with version 1.0.0 as soon as possible, and plan your transition to it.

Improvements in 1.0.0

Enhancements

  • Allow deploying OCI charm resources from private registries by @kian99 in #924.
  • Handle partial app deployments by @kian99 in #926.
  • Add a storage pool resource by @ale8k in #908.
  • Add a storage pool data source by @ale8k in #928

Bug fixes

  • Fix for #671 by @ale8k in #925
  • Making storage field in juju_application read only by @ale8k in #943
  • Fix for resource update in juju_application by @kian99 in #947

Documentation

  • Documentation on plan upgrade to provider 1.0.0 by @kian99 in #883
  • Documentation on creating dependency in deployment by @yanksyoon in #927
  • Update to juju_application resource examples by @kian99 in #939
  • How to use Juju CLI in Terraform plans by @kian99 in #949
  • Examples for juju_ssh_key from Github and Launchpad by @tmihoc in #953

CI & Maintenance

Breaking changes

To make the Juju Terraform provider more future proof in a setting with a multitude of Juju controllers and models we are taking this opportunity to change the way users refer to models. In Juju, a model is uniquely identified either by its UUID or by its full name, which is <model owner>/<model name>. Prior to 1.0.0 the Juju Terraform provider schema has a subtle issue in that it only accounts for the model name, not the full <model owner>/<model name> to identify a model.

Example:

resource "juju_model" "development" {
  name = "development"
}

resource "juju_application" "this" {
  name = "my-application"

  model = juju_model.development.name
}

If there were multiple models with the same name, but different owners in a Juju controller, the Terraform provider might have issues correctly identifying the right model (it will choose the first model with the specified name that the user has access to). With the use of JAAS and multiple controllers hosting many models, we expect users will start facing this issue in the near future. An example of this issue would be if many users had a model named development, each in their own namespace. If one of these users had access to a few of these development models created by different owners and tried using Terraform, then the provider might not correctly identify the intended model, with possibly disastrous consequences.

To avoid these issues starting with the 1.0.0 release we deprecated the use of model names in favor of model UUIDs in Terraform plans. The example above will now look like:

resource "juju_model" "development" {
  name = "development"
}

resource "juju_application" "this" {
  name = "my-application"

  model_uuid = juju_model.development.uuid
}

Full details of this change are described in this issue and documentation

Plan migration from 0.23.1 to 1.0.0

We realize any breaking changes are painful, but a move from 0.23.0 to 1.0.0 is one of the few opportunities we have to do them. To make your plans compatible with 1.0.0 follow our guide.

To make this transition easier we have developed an advisory tool that will take an existing tf file as input and replace references to model names with model uuids. Although we have extensively tested the tool, make sure to carefully review proposed changes before committing to them.

The tool is located here and to use it, one simply runs:

go run github.com/juju/terraform-provider-juju/juju-tf-upgrader path/to/file.tf

As always, please read the README.md first and in case of any issues contact the team in our public Matrix channel.

Can I start playing with 1.0.0 now?

Yes! We have released 1.0.0 on Monday Oct 27, 2025. To use it simply update your configuration:

terraform {
  required_providers {
    juju = {
      source = "juju/juju"
      version = "1.0.0"
    }
  }
}
5 Likes