Aiven Terraform Provider: Provisioning Open Source Data Platform as a Service with Infrastructure as Code

The Terraform provider for Aiven.io is an open source data platform as a service integration that enables declarative provisioning and management of Aiven infrastructure. It is distributed as terraform-provider-aiven and is intended to be used alongside the official Aiven documentation to learn about all the possible services and resources that can be managed through code. The provider is licensed under the MIT license with full license text available in the LICENSE file. The project explicitly does not require a CLA from its contributors. The original version of the Aiven Terraform provider was written and maintained by Jelmer Snoeck. Security issues or serious vulnerabilities should be reported via the security policy maintained by the project.

The Aiven Platform organizes workloads using organizations, organizational units, and projects to organize services. The provider exposes resources and data sources that map to those concepts, allowing Terraform configurations to create an organization with two organizational units and add projects to those units. Example configurations for that pattern are published in the Aiven Terraform Provider repository on GitHub and in the Aiven documentation.

Provider Installation and Authentication

Before any resources can be declared, an Aiven account must be created and an authentication token generated. The token is used as the credential for the provider block.

A minimal provider configuration is required in main.tf:

```hcl
terraform {
required_providers {
aiven = {
source = "aiven/aiven"
version = "x.y.z" # check out the latest version in the release section
}
}
}

provider "aiven" {
api_token = "your-api-token"
}
```

The requiredproviders block pins the aiven/aiven source and a version constraint. The provider block accepts apitoken as the authentication mechanism. In practice users create a file named main.tf with the content above and replace the placeholder token with a valid Aiven authentication token.

A common pattern for multi-file setups separates variables from configuration. The documentation describes creating a file named variables.tf to declare input variables and a terraform.tfvars file to assign values to the variables for the token and the project names. This keeps secrets out of version control while keeping the module reusable.

Initializing and Applying a Configuration

The standard Terraform workflow applies to the Aiven provider.

Initialize Terraform by running:

bash terraform init

The output is similar to the following:

Initializing the backend... Initializing provider plugins... - Finding aiven/aiven versions matching ">= 4.0.0, < 5.0.0"...

After initialization, an execution plan can be created and previewed:

bash terraform plan

To deploy changes, run:

bash terraform apply --auto-approve

The provider documentation recommends running terraform init followed by terraform plan and terraform apply for all service creations. For PostgreSQL, the post-apply command pattern shown is:

bash psql "$(terraform output -raw postgresql_service_uri)"

That command pulls the sensitive service URI output from the state and connects with psql. Voilà, a PostgreSQL database.

Core Service Example: PostgreSQL

A concrete example for a PostgreSQL service is provided in the reference material. The resource aivenpg.postgresql is configured with project, servicename, cloudname, plan, and terminationprotection.

```hcl
resource "aivenpg" "postgresql" {
project = "your-project-name"
servicename = "postgresql"
cloudname = "google-europe-west3"
plan = "startup-4"
terminationprotection = true
}

output "postgresqlserviceuri" {
value = aivenpg.postgresql.serviceuri
sensitive = true
}
```

The configuration demonstrates several important attributes:

• project - the Aiven project name under which the service is created
• service_name - the identifier for the service within the project
• cloud_name - the cloud region, exemplified as google-europe-west3
• plan - the service plan, exemplified as startup-4
• termination_protection - a boolean flag that prevents a service from being deleted by Terraform

The output block exposes aivenpg.postgresql.serviceuri as a sensitive output, allowing downstream consumption by other resources or by CLI commands.

Stateful Service Recreation Risk

Recreating stateful services with Terraform will possibly delete the service and all its data before creating it again. This is a critical operational consideration for databases, Kafka clusters, and other data-holding services. Termination protection mitigates accidental deletion of the service itself, but while it prevents a service to be deleted, any logical databases, topics or other configurations may be removed even when this section is enabled. Be very careful.

The note emphasizes that termination_protection is not a complete data safety net. Logical databases, topics or other configurations may still be removed during a recreation or update. Users must treat stateful resources with caution and review plans carefully before applying.

Organization and Project Modeling

Use the Aiven Provider for Terraform to provision and manage your Aiven infrastructure. Get started by modeling the Aiven Platform hierarchy.

The Aiven Platform uses organizations, organizational units, and projects to organize services. This example shows you how to use the Aiven Provider for Terraform to create an organization with two organizational units, and add projects to those units.

The workflow for that example involves:

• Create a file named main.tf and add the following configuration
• Create a file named variables.tf and add the following
• Create the terraform.tfvars file and assign values to the variables for the token and the project names

The same pattern applies to services and integrations. Next steps recommended by the documentation include:

• Follow an example to set up your own organization with a user group and permissions
• Try one of the other examples to learn how to create a service or integration using the Aiven Terraform Provider
• Get details about all the available resources and data sources in the Aiven Provider for Terraform documentation

Provider Maintenance and Community

The provider repository is hosted at https://github.com/aiven/terraform-provider-aiven. Bug reports and patches are very welcome, please post them as GitHub issues and pull requests at that location. Please review the guides below for contribution expectations. Please see our security policy to report any possible vulnerabilities or serious issues.

The project history notes that the original version of the Aiven Terraform provider was written and maintained by Jelmer Snoeck. The current project is open source and licensed under MIT with no CLA requirement for contributors.

Reference Tables

Provider Configuration Attributes

PostgreSQL Resource Attributes

Terraform Workflow Commands

Conclusion

The Aiven Terraform provider provides a complete path from authentication to service deployment using Infrastructure as Code. The provider requires an Aiven authentication token and a minimal provider block with source aiven/aiven and a version pin. Configuration files named main.tf, variables.tf, and terraform.tfvars are used to separate logic, variables, and values for token and project names.

The example PostgreSQL resource illustrates the core attributes project, servicename, cloudname, plan, and terminationprotection, with a sensitive output for serviceuri. Operational safety notes emphasize that termination_protection prevents service deletion but does not protect logical databases, topics or other configurations from removal, and that recreating stateful services can delete the service and all its data before recreation.

The provider supports the full Aiven organizational model with organizations, organizational units, and projects, enabling creation of organizations with multiple units and projects attached. Initialization, planning, and apply workflows follow standard Terraform conventions, with provider version resolution visible during terraform init and plan output before apply.

Maintenance is community driven via GitHub issues and pull requests at https://github.com/aiven/terraform-provider-aiven, with MIT licensing, no CLA requirement, and a security policy for vulnerability reporting. The original author Jelmer Snoeck established the provider, and current examples are available in the Aiven Terraform Provider repository on GitHub and in the Aiven documentation. Users are encouraged to follow examples for organization setup with user groups and permissions, and to explore additional service and integration examples in the official provider documentation.

Sources

1. Terraform Provider for Aiven
2. Aiven Terraform Documentation