The Cloud is Scarier Than You Think

We’ve been sold a story.

The story goes like this: servers are complicated, scary, and best left to the experts. The cloud is simple, managed, and worry-free. Just click a few buttons, swipe your credit card, and let Amazon/Google/Microsoft handle the hard stuff.

But here’s what nobody tells you: if you’ve ever debugged a Lambda timeout, fought with IAM policies, or spent an afternoon deciphering a CloudFormation error, you already know how to manage a server. You’re just doing it with extra steps, and a much bigger bill.

The Complexity Didn’t Disappear, It Just Got a Marketing Budget

Let me tell you about something that happened in December 2025. Cloudflare — one of the largest infrastructure providers on the internet, powering roughly 20% of all websites — went down. Not once, but twice in three weeks.

The December 5th outage took down 28% of all HTTP traffic they serve. The cause? A configuration change that propagated globally within seconds. One bad update, and suddenly a quarter of the internet is showing 500 errors.

Three weeks earlier, on November 18th, a similar incident. Same pattern: a single change, global propagation, widespread failure.

These aren’t small startups making rookie mistakes. This is Cloudflare — a company with some of the best engineers in the world, declaring “Code Orange” and admitting they need to fundamentally rethink how they deploy changes.

The cloud isn’t magic. It’s just someone else’s servers, wrapped in a dashboard and a billing system.

The Irony of “Managed” Services

Here’s what I find fascinating: we’re told that AWS, GCP, and Azure are “easier” than managing our own infrastructure. But let’s be honest about what “easy” looks like in practice:

• 47 different compute services on AWS alone. EC2, ECS, EKS, Fargate, Lambda, App Runner, Lightsail… Which one do you need? Good luck figuring that out without a week of research.
• IAM policies that read like ancient legal documents. “Effect”: “Allow”, “Action”: “s3:”, “Resource”: “arn:aws:s3:::my-bucket/” — and that’s a simple one.
• CloudFormation templates that span thousands of lines, with cryptic error messages that make you question your career choices.
• Billing surprises that arrive like unexpected guests. “Oh, you left that NAT Gateway running? That’ll be $500, please.”

Meanwhile, on a Linux server:

• apt install nginx
• systemctl start nginx
• ufw allow 80

Which one is actually simpler?

You Already Have the Skills

Here’s the thing that cloud providers don’t want you to realize: if you can navigate the AWS console, you can navigate a terminal.

Think about it:

• If you can write Terraform, you can write a cloud-init config
• If you can read CloudWatch logs, you can run journalctl
• If you can configure IAM roles, you can manage Linux users
• If you can set up a VPC with security groups, you can configure ufw

The skills transfer. The mental models transfer. You’re already doing infrastructure-as-code, and you’re just paying a premium for the privilege of vendor lock-in.

Docker Changed Everything (And Not How You Think)

Remember when “deploying to production” meant carefully following a 47-step checklist, praying you didn’t miss a dependency?

Docker changed that. But here’s what’s funny: Docker works exactly the same on your $5/month VPS as it does on a $500/month EKS cluster.

docker compose up -d

That’s it. Same containers. Same images. Same experience. Except on your own server, you don’t need to:

• Configure cluster autoscaling (more about that later)
• Set up service discovery
• Debug networking between Fargate tasks
• Figure out why your ECS service won’t drain properly

You just… run containers. Like it’s supposed to work.

Cloud-Init: The Best Kept Secret

Cloud-init has been around for over a decade. It’s what powers the “user data” field in AWS EC2. But here’s the thing — it works everywhere. Hetzner, DigitalOcean, Vultr, or just a plain Linux box.

One YAML file. That’s it:

#cloud-config
packages:
  - docker.io
  - fail2ban
  - ufw
users:
  - name: deploy
    groups: docker
    ssh_authorized_keys:
      - ssh-ed25519 AAAA... your-key
runcmd:
  - ufw allow OpenSSH
  - ufw allow 443
  - ufw enable

Compare that to setting up an equivalent environment in AWS:

• VPC with subnets
• Security groups
• IAM roles
• EC2 instance
• Systems Manager for SSH (because apparently ssh user@server is too simple)

Which one would you rather debug at 3 AM?

The Real Question

The question isn’t “Can I manage a server?” — you already can.

The real questions are:

• Do I want to keep paying the cloud tax?
• Do I want my infrastructure dependent on a provider that might change their pricing at any moment?
• Do I want to be at the mercy of their outages?
• Do I want to explain to my CFO why the AWS bill tripled this quarter?

When 37signals left the cloud, they saved over $7 million over five years. And that’s not a small startup — that’s a company running Basecamp and HEY, serving millions of users.

“Just Close the Main Door”

At the last Rails World, DHH said something that stuck with me: “Just close the main door.”

We’ve been convinced that security requires enterprise-grade complexity. Kubernetes. Service meshes. Zero-trust networks. Defense in depth with seventeen layers.

But for most applications? You need:

• A firewall (three commands with ufw)
• SSH keys (no passwords)
• Automatic security updates
• Fail2ban to block brute force attempts

That’s it. That’s the “main door.” And it takes about 10 minutes to set up.

What This Blog Will Be

This is the first post on FreeFrom.Cloud, and I want to be clear about what we’re building here.

This isn’t about being anti-cloud for ideological reasons. Cloud services have their place. But somewhere along the way, we forgot that simpler options exist.

In the coming posts, we’ll cover:

• Server hardening — securing your box in under 30 minutes
• Zero-downtime deployments — with tools you already know
• Database management — backups, replication, without managed services
• Monitoring and alerting — because you need to know when things break
• Cost analysis — real numbers, real comparisons

No gatekeeping. No “you should have learned this 20 years ago.” Just practical, modern approaches to running your own infrastructure.

Because the cloud isn’t scary. Your own server isn’t scary either.

What’s actually scary? Handing over your entire infrastructure to a provider that can change their pricing, terms, or availability at any moment — and having no idea how you’d survive without them.

Let’s fix that.

This is the first post in the FreeFrom.Cloud series. Subscribe to get notified when new posts drop.