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 has to survive a home ISP outage. A second backup copy that should not share a building with the first. DigitalOcean droplets have quietly become the answer to "this needs to live somewhere else" more often than any other tool in this homelab. Here is the honest take after months of depending on them.

What it's actually been used for

Not one droplet spun up once and left running. A changing set of them. A game-server relay handling real player traffic. A production chat application's backend. A dedicated infra-testing twin, built so risky changes get tried somewhere that is not production. And at various points a second, independent backup target for real offsite coverage. Droplets get built, used hard, and torn down when they have served their purpose. This is not one server that has been running for years. It is the operational pattern of standing infrastructure up and down as needs change.

What's genuinely solid

• The metadata service. A simple internal HTTP endpoint every droplet can query about itself. Region, hostname, droplet ID. A small thing that removes a lot of manual bookkeeping when you script against droplets instead of 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 safety net before anything risky, and restorable without drama.
• Pricing that lets you match spend to real usage. Several droplets in active use at any time cost single-digit to low-double-digit dollars a month each. Tearing one down the moment it stops earning its keep is frictionless. No lingering commitment. No penalty for trying something and deciding it was not worth keeping.

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

Be honest about what this is not. It is not a diagnosed DigitalOcean-side problem. It could be the automation client making the connections. It could be a routing quirk between specific networks. It could be something else that correlates with "direct public IP" without being caused by it. What is real is the pattern holding across multiple unrelated droplets over months. If you script against a droplet and hit intermittent SSH timeouts that do not reproduce when you try by hand a minute later, try a tunneled path before you assume something is fundamentally broken.

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

If you already run a tunnel for something else, it is tempting to reach for the same tool to "hide" a new droplet from the internet. Be precise about what a generic tunnel does. It changes which address traffic arrives at. It adds no access control of its own. That solves a NAT problem. A cloud droplet does not have a NAT problem. It already has its own public IP. What restricts who can reach it is a firewall rule scoped to a specific source IP. DigitalOcean's Cloud Firewall does this for free, enforced at the network edge before traffic reaches the droplet. Reach for that first. Layering a tunnel on top of a droplet that already has a public IP adds complexity without adding the restriction you wanted.

Verdict

For "this needs a public IP and does not 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 get used instead of skipped. The one asterisk is the unexplained SSH-under-automation flakiness. Annoying, reliably worked around, and still an open question after months of hitting it. Better to know that going in than to discover it mid-incident and assume something is uniquely broken about your setup.