The Linode Terraform provider is the official bridge between Terraform and the Linode Cloud platform. It is maintained by Linode and enables management of Linode instances, block storage, NodeBalancers, Kubernetes clusters, and more through infrastructure as code. The provider can be used to migrate existing workloads from the Linode web console to Terraform or to build new environments from scratch with versioned, declarative configuration. Documentation for the provider is available at https://www.terraform.io/docs/providers/linode/index.html and the website is https://www.terraform.io. Additional documentation and examples are provided in the Linode Guide, Using Terraform to Provision Linode Environments. Community discussion is available via the Google Groups mailing list.
Provider Overview and Maintenance
The provider plugin is maintained by Linode. It supports a broad surface of Linode resources including compute instances, block storage, NodeBalancers, and managed Kubernetes. The provider's simplicity mirrors Linode's own platform, making it easy to get started and maintain. For monitoring your Linode infrastructure, server monitoring, uptime checks, and alerting can be integrated across any cloud platform.
The provider can be obtained from the official repository. To compile the provider locally, a correctly configured GOPATH is required, as well as adding $GOPATH/bin to $PATH. The build process produces a provider binary placed in the $GOPATH/bin directory.
Prerequisites for using the provider in normal operation are:
- Terraform 1.0 or later
- A Linode account
- A Linode personal access token with appropriate permissions
The provider supports both token via variable and environment variable authentication. 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. Store your Linode token securely. Use environment variables in CI/CD and never commit tokens to version control. Use LKE for containerized workloads. The managed Kubernetes service handles control plane management and integrates well with other Linode services.
Building the Provider from Source
Building from source is useful for development, testing, and custom patches.
Clone this repository to: $GOPATH/src/github.com/linode/terraform-provider-linode
The commands are:
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
This will build the provider and put the provider binary in the $GOPATH/bin directory.
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.
Prerequisites and API Token Setup
Getting your API token is the first operational step.
- 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. Store your Linode token securely. Use environment variables in CI/CD and never commit tokens to version control.
Declaring and Configuring the Provider
Provider declaration is done in versions.tf.
terraform {
required_version = ">= 1.0"
required_providers {
linode = {
source = "linode/linode"
version = "~> 3.13"
}
}
}
Provider configuration with an explicit variable:
```
provider "linode" {
token = var.linode_token
}
variable "linode_token" {
type = string
sensitive = true
description = "Linode API personal access token"
}
```
An alternative configuration for remote state bucket setup uses provider version pinning. At the time of writing, the current terraform version is 1.0.11.
terraform {
required_providers {
linode = {
source = "linode/linode"
version = "1.25.0"
}
}
}
provider "linode" {}
A later example pins version 1.25.0 with comment Current latest version as of 2021-12-03.
terraform {
required_providers {
linode = {
source = "linode/linode"
version = "1.25.0" # Current latest version as of 2021-12-03
}
}
}
provider "linode" {}
Environment Variable Authentication
The provider can pick up credentials from environment variables.
Set the token via environment variable:
export LINODE_TOKEN="your-linode-token"
Provider picks up the token from LINODE_TOKEN:
provider "linode" {}
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=<paste-token-here>
Managing Linode Instances and Resources
Managing instances with the provider is declarative.
Create a basic Linode instance:
resource "linode_instance" "web" {
label = "web-server-01"
region = "us-east"
type = "g6-standard-2" # 2 CPU, 4GB
}
A test example for remote backend validation:
```
variable "root_password" {
type = string
description = "Password for the root user"
sensitive = true
}
resource "linodeinstance" "myserver" {
label = "my-server"
image = "linode/debian11"
region = "eu-west"
type = "g6-nanode-1"
}
```
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.
Best Practices for Security and Cost
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. Store your Linode token securely. Use environment variables in CI/CD and never commit tokens to version control. Use LKE for containerized workloads. The managed Kubernetes service handles control plane management and integrates well with other Linode services.
| Practice | Reason |
|---|---|
| Use environment variables for LINODE_TOKEN | Prevents token leakage in version control |
| Enable backups | Protects data at small incremental cost |
| Apply Cloud Firewalls | Default ports are open |
| Monitor bandwidth | Public traffic incurs charges |
| Use LKE for containers | Managed control plane integrates with Linode services |
Using Linode Object Storage as Terraform Remote Backend
Whilst terraform doesn't 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. This enables you to have your state stored remotely, allowing you to safely store your terraform configuration publicly without worrying about leaking sensitive information through the state.
Using Linode as a remote backend doesn't limit you to only managing Linode resources with your new setup. 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. 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.
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.
Initializing State Buckets with Terraform
Setup for a remote backend can be bootstrapped with Terraform itself.
Create a working directory for initial state code:
cd ~/src/infra/terraform
mkdir init-state
cd init-state
Lookup the storage cluster you want to use. Frankfurt, DE is currently the only European region that supports object storage.
data "linode_object_storage_cluster" "primary" {
id = "eu-central-1"
}
Define the bucket. The name must be unique across all Linode object storage, not just in your account.
resource "linode_object_storage_bucket" "tf_state" {
cluster = data.linode_object_storage_cluster.primary.id
label = "my-tf-state"
}
All together:
```
terraform {
required_providers {
linode = {
source = "linode/linode"
version = "1.25.0"
}
}
}
provider "linode" {}
data "linodeobjectstorage_cluster" "primary" {
id = "eu-central-1"
}
resource "linodeobjectstoragebucket" "tfstate" {
cluster = data.linodeobjectstorage_cluster.primary.id
label = "my-tf-state"
}
```
Initialize and apply:
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"
- 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.
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.
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: At the time of writing this article, the current terraform version is 1.0.11. If you're using a newer version, it's possible that the syntax/format could have changed so make sure you're using the correct syntax for your version.
Conclusion
The Linode Terraform provider delivers full infrastructure as code control over compute, storage, networking, and Kubernetes resources. The provider is maintained by Linode and can be built from source with a correctly configured GOPATH and make. Operational use starts with obtaining a personal access token from the Linode Cloud Manager profile, declaring the provider with source linode/linode and an appropriate version constraint, and supplying credentials via variable or the LINODE_TOKEN environment variable.
Best practices emphasize secure token handling, environment variable usage in CI/CD, backup enablement, bandwidth awareness, and Cloud Firewall adoption. For state management, Linode Object Storage provides an S3 compatible remote backend. Although Terraform does not natively support Linode as a backend, the S3 compatibility allows state to be stored remotely in a private bucket created by Terraform itself. This pattern separates sensitive state from public configuration and enables safe collaboration.
The provider's simplicity mirrors Linode's platform, making it practical to define individual instances, object storage buckets, and managed Kubernetes clusters in versioned code. With the provider configured and a remote backend established, infrastructure can be provisioned, updated, and destroyed reproducibly across environments.