Why I Finally Stopped Overthinking Container Deployments and Just Used Lightsail

I spent three years overthinking my deployment strategy. EC2 with auto-scaling groups, ECS clusters, Kubernetes on EKS—I'd read every architectural decision document and convinced myself that anything less was "not production-ready." Then I deployed WordPress on a single Lightsail instance with Docker, and it actually just... worked. No complexity theater. No 2 AM alarms about cluster networking. Just a container running reliably while I focused on actual product work.

The irony hit me hard: I was optimizing for a scale problem I didn't have. Most of my consulting clients weren't Netflix. They were small agencies, SaaS startups with hundreds of users, and content creators who needed their WordPress site to stay online without paying DevOps salaries. For them, Lightsail with Docker isn't a compromise—it's the right answer.

The Setup That Actually Makes Sense

The core idea here is refreshingly simple: AWS gives you an Ubuntu VM with Docker pre-installed via a user-data script, a static IP so your DNS doesn't break, and pricing that won't spike unexpectedly. You're not managing infrastructure-as-code marathons or debugging network ACLs at midnight.

What impressed me about the approach in that original article is the acknowledgment that you need SSH keys done right from the start. I've seen too many developers create instances with browser-generated key pairs, then panic when they lose them. Generating your own key pair first, storing it properly, then launching the instance—that's thinking defensively about operations.

The user-data script is where this gets practical. Instead of manually SSHing in and running installation commands, you define everything upfront: Docker, Docker Compose, maybe nginx or other tools. When your instance launches, everything's ready. No "wait, did I install the right version?" moments.

What I'd Do Differently (And Why)

Here's where I have to be honest about what I'd actually change for a production setup.

First, that static IP is critical, but I'd go further—I'd add a CloudWatch alarm to monitor the instance's CPU and disk usage. Lightsail doesn't hold your hand like RDS does. You're managing the OS, so you need visibility into what's happening. A runaway Docker container eating memory? You won't know until the site is down.

Second, user-data scripts are great for repeatability, but they obscure what's actually running on the machine. I've inherited instances where nobody remembered what was installed or why. I now document the user-data script heavily in comments and version control it. Future-me will thank present-me.

Third—and this is the honest bit—I wouldn't recommend this setup for anything handling sensitive user data without additional hardening. You're managing security patches yourself. Lightsail doesn't automatically apply OS updates. That's either a feature (you control when restarts happen) or a liability (you have to remember to do it). For WordPress with proper plugins and a WAF, it's fine. For storing PII or payment data? I'd push back.

The Code That Matters

Here's what a reasonable user-data script looks like:

#!/bin/bash
set -e

# Update system
apt-get update && apt-get upgrade -y

# Install Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

# Install Docker Compose
curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

# Add ubuntu user to docker group
usermod -aG docker ubuntu

# Create app directory
mkdir -p /opt/app
cd /opt/app

echo "Docker installation complete"

That set -e line is important—it stops execution if anything fails. You don't want a half-configured machine running in production because one command was silently skipped.

The Real Question This Raises

Reading through the original approach made me realize I don't see enough developers asking the right sizing question upfront. "Should I use Lightsail?" depends entirely on your traffic patterns and data requirements, not your ego or architectural preferences.

For a single WordPress site serving under 100 concurrent users? Lightsail wins. For microservices handling millions of events? Different problem. I wish more deployment guides acknowledged this trade-off explicitly instead of implying one approach fits all scenarios.

So What's Next?

If you're building something small enough to run on Lightsail, I'd actually recommend this pattern. But before you launch, answer three questions: What happens if this instance fails completely? How will you monitor it? And when does it actually become too small?

The moment you can't answer those questions honestly is the moment you probably do need ECS or Kubernetes. Until then, Lightsail is your friend.

Source: This post was inspired by "AWS Lightsail Instance for Docker" by Dev.to. Read the original article