Managing infrastructure alone is a high-wire act where your local laptop is the only thing keeping your production environment from falling into the void. To survive, you need to stop treating Terraform like a local script and start treating it like a production service.

Solo Terraform: How to Manage Infrastructure Without Losing Your Mind (or Your Data)

I’ve been where you are. Back in my early days at a small startup, I was the “everything guy.” I had a prod-db-01 instance that I’d spun up via Terraform from my old MacBook. One afternoon, that laptop’s logic board decided to quit life. Suddenly, I had a live, breathing database and absolutely no way to manage it because my state file—the “brain” of my infrastructure—was trapped on a dead SSD. I spent the next 48 hours manually importing resources into a fresh state file while sweating through my shirt. It was the kind of stress that ages you five years in a weekend.

The Root Cause: The “Local State” Trap

The biggest mistake solo devs make is keeping their terraform.tfstate on their local machine. Terraform isn’t just code; it’s a mapping of your code to real-world resources. When you run it locally, you lack locking (preventing two processes from changing things at once) and durability. If you lose that file, or if you accidentally run an apply with an outdated local file, Terraform will assume your infrastructure is gone and try to “fix” it by deleting everything still standing.

Solution 1: The Quick Fix (Remote State)

If you do nothing else, move your state file to a remote backend immediately. For AWS users, this means an S3 bucket with versioning enabled and a DynamoDB table for locking. This ensures that even if your laptop explodes, your infrastructure map is safe and “locked” during updates.

terraform {
  backend "s3" {
    bucket         = "techresolve-tf-state"
    key            = "global/s3/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Pro Tip: Always enable “Versioning” on your S3 state bucket. If you ever corrupt your state, you can just roll back to the previous version in the AWS console. It’s a literal time machine for your infrastructure.

Solution 2: The Permanent Fix (Directory-Based Isolation)

Don’t put everything in one main.tf. As a one-man team, you’ll be tempted to keep it simple, but a single mistake in a small VPC change shouldn’t risk your production database. Break your project into folders like network, data-storage, and app-layer. Use separate state files for each.

Solution 3: The “Nuclear” Option (GitOps for One)

Even if you’re alone, stop running terraform apply from your terminal. It’s a bad habit. The “Nuclear” option—which is actually the safest—is to set up a CI/CD pipeline using GitHub Actions or Terraform Cloud. You push code to a branch, it runs a plan, you review the output in the PR, and only then do you merge to main to trigger the apply.

Is it “overkill” for one person? Maybe. But when you’re looking at a plan that says “Plan: 0 to add, 1 to change, 55 to destroy”, you’ll be glad you had that extra step to catch the error before it hit the API.

# A simple "safety check" workflow
name: Terraform Plan
on: [pull_request]
jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - checkout
      - run: terraform init
      - run: terraform plan -out=tfplan

Look, I know it feels like extra work when you just want to ship features. But trust me: an hour spent setting up backends and pipelines today saves you a week of disaster recovery tomorrow. Don’t be “Past Darian.” Be the engineer who can sleep through the night.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions