Terraforming on Linode (and realising it’s not just “spin up a server”)

The Linode docs for Terraform and OpenTofu are a bit behind.

So this is a rewrite. Not a perfect one, just one that reflects how this actually goes when you sit down and try to build something useful.

The bit that sounds simple

Infrastructure as code is fairly straightforward in principle.

You describe what you want.
You run a plan.
You apply it.

Something gets built.

OpenTofu follows the same pattern:

tofu init
tofu plan
tofu apply

That’s the loop.

And the first time you do it, it feels clean. No clicking around, no trying to remember what you changed last time, just code and a predictable outcome.

A minimal example

You do not need much to get started.

terraform {
  required_providers {
    linode = {
      source  = "linode/linode"
      version = "~> 3.8"
    }
  }
}

provider "linode" {}

resource "linode_instance" "web" {
  image           = "linode/ubuntu24.04"
  label           = "tofu-web"
  region          = "us-east"
  type            = "g6-standard-1"
  authorized_keys = ["YOUR_PUBLIC_SSH_KEY"]
  root_pass       = "YOUR_ROOT_PASSWORD"
}

Run that, and you get a server.

That part works exactly as advertised.

Where it stops being just a demo

Very quickly, you notice the rough edges.

You have hardcoded secrets.
You want more than one instance.
You want consistency.
You want something you can come back to later without having to re-learn your own decisions.

So you start adding:

• variables
• separate files
• maybe modules
• remote state

And that is usually the point where it stops being “spin up a server” and starts becoming actual infrastructure work.

A few things worth doing early

Nothing dramatic, just things that save you pain later:

• do not hardcode secrets
• commit your lock file
• split config so it stays readable
• use remote state if more than one person is involved
• actually read plan before you run apply

None of that is glamorous, but it is the difference between something working once and something being manageable.

Changing things later

One of the useful parts of working this way is that you can change the config and let the tool tell you what happens next.

tofu plan
tofu apply

If the provider supports the change in place, great.

If not, it will tell you it wants to replace something.

That is where reading the output properly starts to matter.

Destroying things

You will need this eventually.

tofu destroy

Or if you want to preview it first:

tofu plan -destroy

At some point you will run one of those with more confidence than you should have had. That seems to be part of the learning process.

The bit nobody really says out loud

Getting something working is easy.

Getting something you understand, can change safely, and will still trust later is where the actual work starts.

Because now you are thinking about:

• structure
• state
• access
• recovery
• what breaks if this changes
• what happens if you need to hand it to someone else

That is the difference between “a config file” and “a system”.

On just getting it working

There is a version of this where you move quickly, get something deployed, and call it done.

That works, right up until it does not.

You end up with unclear configuration, hidden assumptions, security gaps you did not notice at the time, and no easy way to unwind any of it later.

It is very easy to build something that works.

It is harder to build something you can still reason about in a month.

Final thought

OpenTofu on Linode is still a very good place to start.

You can build quickly, learn by doing, and break things in a way that is recoverable enough to be educational.

Just do not mistake “it works” for “it is finished”.

That second part is where most of the useful learning actually lives.