Infrastructure as code for the Akamai cloud platform starts with a correctly declared provider, secure token handling, and a reliable remote state backend. The Linode Terraform provider lets you manage Linode instances, block storage, NodeBalancers, Kubernetes clusters, and more through infrastructure as code. Whether you are migrating from the Linode web console to Terraform or building new infrastructure from scratch, the setup process covers provider compilation, authentication, resource management, and remote state using Linode Object Storage.
The provider plugin is maintained by Linode. Additional documentation and examples are provided in the Linode Guide, Using Terraform to Provision Linode Environments. The official documentation lives at the Terraform provider index page for Linode and the project is hosted on GitHub.
Provider Acquisition and Local Build
The Terraform Linode provider can be used from the public registry or built locally from source. Local builds require a correctly configured GOPATH, as well as adding $GOPATH/bin to your $PATH.
To compile the provider, run make. This will build the provider and put the provider binary in the $GOPATH/bin directory.
Clone steps from reference:
- mkdir -p $GOPATH/src/github.com/linode
- cd $GOPATH/src/github.com/linode
- git clone https://github.com/linode/terraform-provider-linode.git
Enter the provider directory and build the provider:
- cd $GOPATH/src/github.com/linode/terraform-provider-linode
- make
In order to run the full suite of Acceptance tests, run make test-int. Acceptance testing will require the LINODE_TOKEN variable to be populated with a Linode APIv4 Token.
The provider is distributed via Terraform Registry under source linode/linode. The website is https://www.terraform.io and the documentation URL is https://www.terraform.io/docs/providers/linode/index.html. Mailing list support is via Google Groups.
Prerequisites and Authentication
Before declaring the provider you need the following:
- Terraform 1.0 or later
- A Linode account
- A Linode personal access token with appropriate permissions
Getting Your API Token:
- Log in to the Linode Cloud Manager
- Go to your profile by clicking your username in the top right
- Select API Tokens
- Click Create a Personal Access Token
- Set the expiry and permissions, Read/Write for the resources you need
- Copy the token
Make sure you save the token somewhere safe like a password manager as once you close the popup, you won't be able to see the token again.
For the Linode provider to access this token, you can just run the terraform commands and it will prompt for the token. If you don't want to enter it each time, you can set the LINODE_TOKEN environment variable instead with the token as the value.
export LINODE_TOKEN=
Store your Linode token securely. Use environment variables in CI/CD and never commit tokens to version control.
Declaring and Configuring the Provider
Declare the provider in versions.tf:
hcl
terraform {
required_version = ">= 1.0"
required_providers {
linode = {
source = "linode/linode"
version = "~> 3.13"
}
}
}
Provider configuration in provider.tf:
```hcl
provider "linode" {
token = var.linode_token
}
variable "linode_token" {
type = string
sensitive = true
description = "Linode API personal access token"
}
```
Using Environment Variables:
hcl
export LINODE_TOKEN="your-linode-token"
The provider picks up the token from LINODE_TOKEN when the provider block is empty.
hcl
provider "linode" {}
Table of provider configuration options
| Item | Value | Notes |
|---|---|---|
| required_version | >= 1.0 | Terraform minimum |
| provider source | linode/linode | Registry source |
| provider version | ~> 3.13 | Example constraint |
| authentication method | token var or LINODE_TOKEN | Sensitive string |
| build tool | make | Produces binary in $GOPATH/bin |
Managing Linode Resources
The provider exposes resources for instances, block storage, NodeBalancers, and Kubernetes clusters.
Example instance:
hcl
resource "linode_instance" "web" {
label = "web-server-01"
region = "us-east"
type = "g6-standard-2" # 2 CPU, 4GB
}
Additional example with variable for root password:
```hcl
terraform {
required_providers {
linode = {
source = "linode/linode"
version = "1.25.0" # Current latest version as of 2021-12-03
}
}
}
provider "linode" {}
variable "rootpassword" {
type = string
description = "Password for the root user"
sensitive = true
}
resource "linodeinstance" "my_server" {
label = "my-server"
image = "linode/debian11"
region = "eu-west"
type = "g6-nanode-1"
}
```
Operational guidance from the provider guide:
- Public traffic incurs bandwidth charges.
- Enable backups for any instance with important data. It is a small percentage of the instance cost.
- Use Cloud Firewalls to restrict access. Default configurations leave all ports open.
- Use LKE for containerized workloads. The managed Kubernetes service handles control plane management and integrates well with other Linode services.
The Linode Terraform provider gives you full control over your Akamai cloud infrastructure as code. From individual instances to managed Kubernetes clusters, everything can be defined, versioned, and deployed through Terraform. The provider's simplicity mirrors Linode's own platform, making it easy to get started and maintain.
Remote State with Linode Object Storage
Terraform does not directly support Linode as a backend. Linode Object Storage is S3 compatible which means that with only a few extra settings, we can use it as an S3 backend.
In the folder where you want to create your terraform configuration, create a new folder to hold this initial terraform code and cd into it.
bash
cd ~/src/infra/terraform
mkdir init-state
cd init-state
Now we need to add the terraform code to create the bucket. This is pretty simple but can be extended to add extra configuration such as lifecycle rules or versioning.
Note
At the time of writing this article, the current terraform version is 1.0.11
The bucket resource example:
hcl
resource "linode_object_storage_bucket" "state" {
acl = "private"
cluster = "eu-central-1"
cors_enabled = true
id = (known after apply)
label = "my-tf-state"
versioning = (known after apply)
}
Terraform init and apply flow:
bash
terraform init
terraform apply
This should download the Linode provider and then output a plan which looks like this:
Terraform will perform the following actions:
linodeobjectstorage_bucket.state will be created
- resource "linodeobjectstorage_bucket" "state" {
- acl = "private"
- cluster = "eu-central-1"
- cors_enabled = true
- id = (known after apply)
- label = "my-tf-state"
- versioning = (known after apply)
}
Plan: 1 to add, 0 to change, 0 to destroy.
If you're happy with the output, go ahead and type yes to create the bucket!
Before you commit everything to your repo, make sure to add .terraform to your .gitignore as it contains ephemeral data like the downloaded Linode provider which shouldn't be stored in your version control system.
For terraform to be able to use the bucket as a backend, it needs access keys to allow it to read and write to the bucket. To create these keys, go to the Access Keys page and click the Create Access Key button.
Backend configuration notes:
- Next we tell terraform to load the credentials from the linode-s3 profile we created in the AWS config files.
- It's important to set skipcredentialsvalidation to true as otherwise terraform will reach out to AWS STS to try to validate the access keys which will obviously fail.
- Finally we set the bucket name, key, and region. The key is the path in the bucket to the terraform state file.
Initialize terraform with the new backend:
bash
terraform init
You can test it out by creating a Linode resource and running terraform apply.
Note
Terraform will still store a local copy of the state on your machine to make it easier to work with. It is VERY important to make sure you add the .terraform directory to your .gitignore as otherwise this state file could be accidentally committed and all of our hard work will be for nothing!
Once that's done, you should be ready to create some resources with terraform and be safe in the knowledge that your state file is stored in a private Linode bucket!
It's worth noting that using Linode as a remote backend doesn't limit you to only managing Linode resources with your new setup.
The last thing to do is initialise terraform with the new backend. Once that's done, you should be ready to create some resources with terraform and be safe in the knowledge that your state file is stored in a private Linode bucket!
Note
Terraform will still store a local copy of the state on your machine to make it easier to work with
Best Practices Summary
- Keep provider version pinned with ~> constraint for safe upgrades.
- Never commit LINODE_TOKEN or access keys. Use environment variables in CI/CD.
- Use S3 compatible backend for state isolation. Linode Object Storage provides private buckets with ACL control.
- Add .terraform to .gitignore to avoid committing provider binaries and local state copies.
- Enable versioning on state buckets for recovery.
- Validate instance types, regions, and images before apply to avoid drift.
Table of backend configuration elements
| Element | Example | Purpose |
|---|---|---|
| backend type | s3 | S3 compatible remote state |
| bucket label | my-tf-state | Linode Object Storage bucket |
| cluster | eu-central-1 | Object storage region |
| acl | private | Access control |
| skipcredentialsvalidation | true | Avoid AWS STS check |
| credentials profile | linode-s3 | AWS config profile |
Conclusion
The Linode Terraform provider provides a complete infrastructure as code interface for Akamai cloud resources. From local compilation with make and GOPATH setup to registry-based usage with version constraints, authentication is handled cleanly via personal access tokens or the LINODE_TOKEN environment variable. Resource management covers instances, block storage, NodeBalancers, and Kubernetes with explicit guidance on bandwidth costs, backups, and firewall defaults.
Remote state handling adds operational safety. Because Linode Object Storage is S3 compatible, Terraform state can be stored in a private bucket created and managed by Terraform itself. The pattern of bootstrapping a state bucket with linodeobjectstoragebucket, generating access keys, and configuring an S3 backend with skipcredentials_validation enables secure, versioned state storage without leaking secrets. Local state copies remain on the machine for usability, but .terraform must be gitignored to prevent accidental commits.
Together, provider declaration, token hygiene, resource definitions, and S3-backed state form a stable foundation for managing Linode infrastructure as code at scale.