Cloud / Self-Hosting

DigitalOcean — Reviewed After Running Half a Dozen Real Droplets for Months

Not everything belongs on a home connection — public game servers, a chat app that needs to survive a home ISP outage, a second backup copy that shouldn't share a building with the first. DigitalOcean droplets have quietly become the answer to "this needs to live somewhere else" more times than any other single tool in this homelab. Here's the honest take after months of actually depending on them.

What it's actually been used for

Not one droplet spun up once and left running — a real, changing set of them: a game-server relay handling real player traffic, a production chat application's actual backend, a dedicated infra-testing twin built specifically so risky changes get tried somewhere that isn't production first, and (at various points) a second, independent backup target for real offsite coverage. Droplets get built, used hard, and torn down again when they've served their purpose — this isn't "one server that's been running for years," it's the actual operational pattern of standing infrastructure up and down as real needs change.

What's genuinely solid

The metadata service (a simple internal HTTP endpoint every droplet can query about itself — region, hostname, droplet ID) is a small thing that removes a surprising amount of manual bookkeeping when you're scripting against droplets rather than clicking through a dashboard.
Snapshots are exactly as simple as they should be — a real point-in-time image of a whole droplet, useful as a pre-change safety net before anything risky, restorable without drama.
Pricing that actually lets you match spend to real usage: several droplets in active use at any given time cost single-digit-to-low-double-digit dollars a month each, and tearing one down the moment it's no longer earning its keep is genuinely frictionless — no lingering commitment, no penalty for having tried something and decided it wasn't worth keeping.

The recurring quirk nobody's fully explained: direct SSH gets flaky under automation

SSH directly to a droplet's public IP has been intermittently unreliable specifically when driven by automation — and it's never been conclusively root-caused. The workaround that's held up every time: route through an existing WireGuard tunnel instead of the droplet's public IP directly, using an SSH alias that goes over the tunnel rather than the internet path. Every time this has been tested, the tunneled path has been immediately reliable while the direct-IP path kept exhibiting the same intermittent hangs.

Worth being honest about what this isn't: it's not a definitively diagnosed DigitalOcean-side problem — it could just as easily be something specific to the automation client making the connections, a routing quirk between specific networks, or something else entirely that happens to correlate with "direct public IP" without being caused by it. What's real is the pattern holding consistently across multiple, unrelated droplets over months: if you're scripting against a droplet and hitting confusing intermittent SSH timeouts that don't reproduce when you try manually a minute later, a tunneled path is worth trying before assuming something is fundamentally broken.

The access-control lesson: a tunnel isn't a firewall

It's tempting, if you already run a tunnel for something else, to reach for the same tool to "hide" a new droplet from the internet. Worth being precise about what a generic tunnel actually does: it changes which address traffic arrives at — it doesn't add any access control of its own. That solves a NAT problem. A cloud droplet doesn't have a NAT problem; it already has its own public IP. What actually restricts who can reach it is a firewall rule scoped to a specific source IP — DigitalOcean's Cloud Firewall feature does this for free, enforced at the network edge before traffic ever reaches the droplet itself. Reach for that first; layering a tunnel on top of a droplet that already has a public IP usually adds complexity without adding the restriction you actually wanted.

Reminder if you're new to this: a fresh droplet normally has no password set on its root account at all — key-based SSH login only, by design. If something on the droplet needs a password login (a web UI with its own separate auth, for instance), you'll need to set one directly on the droplet first; it won't already have one waiting.

Verdict

For "this needs a public IP and doesn't belong on a home connection," DigitalOcean droplets have been reliably solid — real infrastructure, not a toy, cheap enough to spin up and tear down freely, simple enough that snapshots and firewalls actually get used instead of skipped. The one real asterisk is the unexplained SSH-under-automation flakiness — genuinely annoying, worked around reliably, but still an open question rather than a closed one after months of hitting it. Worth knowing about going in rather than discovering it mid-incident and assuming something is uniquely broken about your setup.