terraform-provider-alicloud moves to a 2.x line and leaves 1.x behind

What the provider covers across Alibaba Cloud

The provider's stated job is allowing management of resources and data sources within Alibaba Cloud, and the breadth is visible in the repository rather than in the README. The examples directory holds a directory per service family, including adb, alikafka with instance, topic, consumer group and SASL ACL variants, api-gateway with api and fc, bastionhost, build-lnmp, cas, cassandra_cluster and cassandra_dc, cdn, cen, cloud_connect_network with attachment and grant, datahub, dbaudit, ddosbgp, ddoscoo, dns and drds.

That list is a good proxy for the provider's real shape. It is a broad surface of many small service adapters rather than a small number of deep ones, and each example is a working configuration you can read as a reference for the resource arguments.

The data source side is mentioned in the same sentence as resources but not illustrated, and the README links to the registry documentation for the full reference. A team choosing between this provider and something else will mostly be choosing between two different coverage stories, so the service list above is the place to start rather than the feature descriptions.

Why 2.0 and not another 1.x patch

The README states the position plainly: the 2.x line is the actively maintained line, and the 1.x line is end-of-life. It also recommends Terraform CLI 1.14 or later.

The release sequence shows how deliberate the cut was. Version 1.294.0 was published on 2026-10-10, the 2.0.0-beta5 tag followed the same day, and 2.0.0 landed on 2026-10-12. The final 1.x release and the 2.0 release are two days apart, which is the shape of a coordinated major version bump rather than an abandoned branch.

For a provider, a major version is not a library API question in the usual sense. Resource argument names, defaults and import formats can all change, and every such change lands in a state file you already hold. The documentation points to the registry for the per-resource details and the repository holds CHANGELOG.md alongside CHANGELOG-v2.md, so the migration notes exist, but the work of reading them is on the team doing the upgrade.

Pinning the provider and creating a first VPC

The README's usage example is short enough to copy, and it covers the three things every configuration needs: the provider version constraint, the provider block, and one resource.

# 1. Specify the version of the Alibaba Cloud Provider to use
terraform {
  required_providers {
    alicloud = {
      source  = "aliyun/alicloud"
      version = "~> 2.0"
    }
  }
}

The version constraint is the interesting part. Writing ~> 2.0 pins the major line while allowing patch updates, which is the right default when 1.x is dead and the 2.x line is where fixes land.

The provider block then selects a region, in the example cn-hangzhou, and the first resource is a VPC with a name and a CIDR block:

provider "alicloud" {
  region = "cn-hangzhou"
}

resource "alicloud_vpc" "example" {
  vpc_name   = "example-vpc"
  cidr_block = "10.0.0.0/16"
}

The credential story is not part of this example, and the README does not walk through it, so the region block is where you would expect provider-specific settings to go once you consult the registry documentation.

Building the provider from source with make

Contributor setup starts with Go, and the README is specific about the version: 1.25.8 or later is required. The go.mod file agrees, declaring the module as github.com/aliyun/terraform-provider-alicloud and the Go language version as 1.25.8.

The build sequence is three commands:

$ git clone https://github.com/aliyun/terraform-provider-alicloud
$ cd terraform-provider-alicloud
$ make tools
$ make build

The targets are documented in the README rather than in a wiki, which is rare and useful. make build compiles the provider for macOS, Linux and Windows and puts the archives under bin/, which tells you the release artefacts are built by the same path contributors use, with a .goreleaser.yml at the repository root.

For local iteration there is a separate set of targets. make dev on macOS, make devlinux on Linux and make devwin on Windows build and install a development provider that replaces the one your local Terraform CLI uses. That last detail is the practical difference between building and testing: a plain build leaves you with archives, while a dev target overrides the provider your CLI will actually load.

Acceptance tests provision real resources and cost money

The test story is two targets with very different risk profiles. The documentation says that in order to test the provider you can simply run make test, and that in order to run the full suite of Acceptance tests you run make testacc.

The parenthetical note in the README is the important sentence: acceptance tests create real resources, and often cost money to run. This is a provider that talks to a billed cloud API, so a test run is not a sandbox exercise. A contributor working on an unfamiliar service needs to know which account and which region the acceptance tests will hit before running them, and the README does not document how to point them at a throwaway project.

For an organisation evaluating the provider, that is a concrete question to answer before enabling acceptance tests in CI. The dev extra lists tooling that hints at the shape of the suite, including cbor2, confluent-kafka, folium, graphviz, h5py, networkx, ortools, pandas and pillow, alongside pytest-cov, pytest-remotedata and pytest-skip-slow, so the suite reaches beyond pure resource creation into serialisation and reporting.

Two cloud SDKs in one dependency list

The go.mod file is long, and one detail in it stands out. Alongside a family of Alibaba Cloud modules, including several alibabacloud-go gateway packages, the Alibaba Cloud OpenAPI client for several dated service versions, the darabonba-openapi runtime and the older alibaba-cloud-sdk-go at v1.63.107, the list also carries github.com/aws/aws-sdk-go-v2 with its credentials package and the dynamodb service client.

Two things follow. The provider depends on more than one generation of Alibaba Cloud client, which is what a codebase with a long history of maintaining hundreds of service adapters looks like, and it reaches outside Alibaba Cloud's own SDK set for at least one workflow. The README does not say which resources involve the AWS client, so it would be guesswork to name them, but it does tell you the provider is not a thin wrapper over a single vendor library.

For a reader trying to judge the upgrade cost of the 2.x move, the dependency list is the honest place to look. A provider that ships many service adapters and two generations of SDK clients carries a larger surface for behavioural change than a small one, which is consistent with a project that ships its final 1.x release and its 2.0 release within two days of each other.

MPL-2.0 terms, release plumbing and who tracks the issues

The provider is released under the MPL-2.0 licence, with the LICENSE file at the repository root. That is a file-level copyleft licence, so if you modify provider source and distribute it you have obligations around those files. Vendoring the provider into an internal image is a different question from shipping a modified copy, and the licence text is the place to read the detail rather than any summary.

The repository carries the expected release plumbing: a .goreleaser.yml, a terraform-registry-manifest.json, a website directory holding the documentation sources, scripts, ci and a .golangci.yml for linting, plus several linter configurations including .mega-linter.yml and .markdown-link-check.json. The repository is not archived and the last push was on 2026-10-20, days after the 2.0.0 release, so the 2.x line is where the work continues.

Issues and feature requests are tracked in the GitHub issue tracker, and the README links the provider documentation on the Terraform Registry as the primary usage reference. For a project this size, the registry documentation is the real interface, and the repository is where the behaviour changes live.

Editorial conclusion

terraform-provider-alicloud fits teams already running Terraform who want Alibaba Cloud resources described in configuration rather than through the console or a script, and the 2.x line is the only one that will receive fixes. It does not fit a team that intends to stay on 1.x, since the README calls that line end-of-life, and it does not fit a shop without a Terraform CLI, since the provider is distributed as a plugin rather than a standalone tool. Before migrating, read CHANGELOG-v2.md against your existing configuration, confirm Terraform CLI 1.14 or later, and rehearse the change with a state refresh on a non-production workspace first.

Frequently asked questions

Official sources

1. aliyun/terraform-provider-alicloud on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases