Tech

Terraform for Tyrants: Infrastructure as Code

October 24, 2025

“Control is not about what you build. It’s about how quickly you can rebuild when the people revolt.” - Kim Jong Rails

Why Dictators Love Infrastructure as Code

Traditional server management is like ruling through fear and manual labor. You SSH into boxes, run commands, hope nothing breaks. When something goes wrong (and it will), you scramble to remember what you did last Tuesday at 3am.

Infrastructure as Code (IaC) is different. It’s centralized planning meets version control. Every server, every configuration, every firewall rule—documented, versioned, and reproducible with a single command.

The Three Pillars of Digital Tyranny

1. Declarative Configuration (What, Not How)

You don’t tell Terraform how to build your infrastructure. You declare what you want, and it makes it happen. Like a decree from the Supreme Leader—you just say “I want a server here” and the cloud obeys.

resource "hcloud_server" "gitea" {
  name        = "gitea-derails"
  image       = "ubuntu-24.04"
  server_type = "cx23"
  location    = "fsn1"

  public_net {
    ipv4_enabled = false  # IPv6-only: save $0.60/month
    ipv6_enabled = true
  }
}

This isn’t a bash script. It’s a declaration of reality. Terraform reads this and makes it so.

2. Idempotency (Run It 100 Times, Same Result)

Apply this configuration once? You get a server. Apply it again? Nothing changes (unless you modified the declaration). Apply it 100 times? Still the same server. No duplicates, no chaos.

This is crucial for dictators who need predictability. No “oops, I created 101 servers” moments.

3. State Management (The Secret Police Files)

Terraform maintains a terraform.tfstate file—a complete record of what exists. It’s like the Stasi files for your infrastructure. Terraform knows:

Every server you’ve created
Every DNS record
Every SSH key
What changed since last time

Real Dictator Use Case: The Derails Stack

Our entire infrastructure—Gitea server, DNS records, Cloudflare settings—is defined in ~150 lines of Terraform.

The Server Definition

# Hetzner Cloud Server - IPv6 only
resource "hcloud_server" "gitea" {
  name        = "gitea-derails"
  image       = "ubuntu-24.04"
  server_type = "cx23"      # 2 vCPU, 4GB RAM, €3.49/mo
  location    = "fsn1"       # Falkenstein, Germany

  public_net {
    ipv4_enabled = false     # Save $0.60/month
    ipv6_enabled = true
  }

  ssh_keys = [data.hcloud_ssh_key.default.id]

  labels = {
    service     = "gitea"
    environment = "production"
    managed_by  = "terraform"
  }

  # Automated installation via cloud-init
  user_data = file("${path.module}/cloud-init-simple.yml")
}

DNS Configuration

# Cloudflare DNS - git.derails.dev
resource "cloudflare_dns_record" "gitea" {
  zone_id = data.cloudflare_zones.derails_dev.result[0].id
  name    = "git"
  content = hcloud_server.gitea.ipv6_address  # Reference the server!
  type    = "AAAA"
  proxied = true
  comment = "Gitea - IPv6 only, Cloudflare proxies IPv4"
}

# SSL mode: Flexible (Cloudflare terminates SSL)
resource "cloudflare_zone_setting" "ssl_flexible" {
  zone_id    = data.cloudflare_zones.derails_dev.result[0].id
  setting_id = "ssl"
  value      = "flexible"
}

The One-Command Revolution

Here’s the beauty: Our entire infrastructure can be destroyed and rebuilt with:

terraform destroy -auto-approve  # Burn it down
terraform apply -auto-approve    # Rise from ashes in 2 minutes

Try doing that with ClickOps in the AWS console. Good luck remembering which checkboxes you clicked.

Why This Matters for Resistance

Scenario: GitHub Bans You (Again)

Without IaC: Panic. SSH into servers. Copy files manually. Update DNS by hand. Break things. Cry.

With IaC:

Change server name in 10-gitea-instance.tf
Run terraform apply
New server spins up, DNS updates automatically
Old server gets destroyed
You’re back in 3 minutes

Scenario: Migrate to New Provider

Hetzner raises prices? Just swap the provider:

provider "hcloud" {
provider "aws" {
  resource "hcloud_server" "gitea" {
  resource "aws_instance" "gitea" {

Adjust resource parameters, run terraform apply, and you’re on AWS. (Though why would you pay 10x more?)

The Dictator’s Workflow

1. Plan Before You Act

terraform plan  # See what will change BEFORE you apply

This shows you a diff of what Terraform will do. Review it like a five-year plan before committing.

2. Apply Changes

terraform apply  # Make it so

Terraform shows the plan again and asks for confirmation. Type “yes” and watch the magic happen.

3. Version Control Everything

git add *.tf
git commit -m "Upgrade to CPX21 for more RAM"
git push origin master

Your infrastructure changes are now documented in Git. You can roll back to any previous state.

4. State is Sacred

Never manually edit terraform.tfstate. This is the nuclear codes. Corruption = chaos.

Store it remotely (S3, Terraform Cloud, etc.) for team collaboration. Or keep it local if you’re a solo dictator.

Common Pitfalls (And How to Avoid the Gulag)

❌ Hardcoding Secrets

# BAD - Never commit secrets!
provider "cloudflare" {
  api_token = "supersecrettoken123"
}

# GOOD - Use environment variables
provider "cloudflare" {
  api_token = var.cloudflare_api_token  # Set via TF_VAR_cloudflare_api_token
}

❌ Deleting State Files

If you lose terraform.tfstate, Terraform forgets what it created. You’ll have orphaned resources billing you forever. Back it up!

❌ Manual Changes in Console

You SSH in and manually edit nginx config? Terraform doesn’t know. Next terraform apply might overwrite your changes. Everything in code.

Advanced Tyranny: Modules

Once you master basic Terraform, create reusable modules:

module "gitea_server" {
  source = "./modules/gitea"

  server_name = "gitea-derails"
  server_size = "cx23"
  domain      = "git.derails.dev"
}

module "blog_server" {
  source = "./modules/astro-blog"

  server_name = "blog-derails"
  domain      = "www.derails.dev"
}

Now you can spin up identical infrastructure with different parameters. Clone your dictatorship!

The Terraform Tyrant’s Toolkit

Providers: Hetzner, AWS, Cloudflare, DigitalOcean, etc.
State backends: S3, Terraform Cloud, Consul
Tools: tflint (linter), terraform-docs (documentation)
Validators: terraform validate before committing

Why Every Resistance Needs IaC

Centralized platforms can ban you with a click. But if your infrastructure is code:

✅ You can rebuild anywhere, anytime
✅ New team members run terraform apply and they’re set
✅ Disasters become minor inconveniences (restore from Git)
✅ You document your setup automatically
✅ Auditable: Every change is in Git history

“The revolution will not be manually configured. It will be terraformed.” - BasharAlCode

Get Started

Our full Terraform configuration is available on our Gitea server. Clone it, modify it, build your own digital sovereignty.

Start small: Define one server. Then add DNS. Then SSL settings. Before you know it, you’re managing entire empires with terraform apply.

Next Steps

📖 Read: HashiCorp Terraform Tutorials
🎯 Try: Spin up a €3.49/month server on Hetzner
🚀 Deploy: Our complete stack from Git

← Back to Blog | Home