DigitalOcean is a popular cloud provider offering virtual machines (Droplets), managed databases, object storage (Spaces), Kubernetes, load balancers, and more. Because of its relatively user-friendly interface and competitive pricing, many developers and hobbyists choose it as their first real cloud environment. But that ease of use can lull beginners into assuming things “just work,” which leads to avoidable misconfigurations, security gaps, scaling woes, and downtime.
Over time I’ve seen (and helped debug) projects break in predictable ways on DigitalOcean. In what follows I’ll walk you through ten pitfalls I see often, show you example commands or configurations, and suggest best practices. You can treat this as a “Debug Before It Breaks” checklist. Keep this guide open when you set up or maintain your Droplets or apps.
1) Using password logins instead of SSH keys
Attackers brute-force SSH on public IPs all day. If you leave password auth on (especially for root), you are inviting them in. Create an SSH key pair locally, add the public key during Droplet creation, then disable password auth and root login. This prevents credential stuffing and closes off a huge risk surface.
Edit your SSH daemon config, then reload:
# On your Droplet (Ubuntu/Debian):
sudoedit /etc/ssh/sshd_config
# Set or ensure:
# PermitRootLogin no
# PasswordAuthentication no
sudo systemctl reload sshIf you ever lose your private key, regain access via the Recovery Console and temporarily re-enable password auth—then rotate keys immediately.
2) Skipping backups and snapshots
People plan to “add backups later” and then a bad deploy or rm -rf wipes data. DigitalOcean offers automatic Droplet backups (weekly or daily) and on-demand snapshots; enable one or both from day one. Weekly backups cost 20% of the Droplet price; daily backups cost 30%. Snapshots are $0.06/GB-mo. Backups are point-in-time full-disk images you can restore quickly; snapshots are great before risky changes. Test restores quarterly.
Create a quick safety snapshot before big edits or upgrades:
# Using doctl (DigitalOcean CLI) from your laptop:
doctl auth init # paste your API token
doctl compute droplet list
doctl compute droplet-action snapshot <DROPLET_ID> --snapshot-name "pre-upgrade-$(date +%F)"3) Choosing the wrong region (and ignoring latency)
Putting your app in a region far from users adds latency to every request. During creation, pick the datacenter closest to your users; it’s the simplest performance win. For global audiences, push static assets to a CDN (see mistake #10) and consider load balancers + multi-region if needed. DigitalOcean documents regional availability and explicitly recommends choosing the nearest region for minimal latency. Uptime monitoring can also chart latency by region over time.
If you need to move, you can snapshot the Droplet, recreate it in a new region, and swing the IP/DNS (ideally with a Reserved IP—see #8).
4) Leaving ports open to the world (and not isolating networks)
If a service is listening, it’s reachable unless you block it. Don’t expose MySQL, Redis, or admin panels publicly. Use Cloud Firewalls to allow only what you need (e.g., SSH from your IP; HTTP/HTTPS from anywhere) and keep databases private. Cloud Firewalls are network-level, stateful, and free; they default-deny all traffic not explicitly permitted. Pair them with a VPC so internal traffic between Droplets and managed databases never touches the public internet (and doesn’t count against bandwidth).
Create a minimal firewall with doctl (open 22/80/443; everything else denied by default):
doctl compute firewall create \
--name web-min \
--inbound-rules "protocol:tcp,ports:22,sources:addresses:YOUR.IP.ADDR.ONLY" \
--inbound-rules "protocol:tcp,ports:80,sources:0.0.0.0/0,::/0" \
--inbound-rules "protocol:tcp,ports:443,sources:0.0.0.0/0,::/0"Create and attach a VPC before you deploy databases, then keep DB ports open only to that VPC.
5) Under- or over-sizing Droplets (and never monitoring)
Guessing capacity leads to either slow apps or wasted money. Start small, monitor, and scale when the graphs tell you. DigitalOcean Monitoring is free and supports real-time CPU, RAM, disk I/O, and alerts delivered to email or Slack. Combine it with Uptime checks for external availability and latency.
Create a basic uptime check and alert with doctl:
# Create an uptime check for your site
doctl monitoring uptime create my-site --protocol https --target https://example.com --regions "us,eu,asia"
# Create a latency alert on that check (adjust threshold/notification targets)
doctl monitoring uptime alert create --uptime-check-id <CHECK_ID> --type latency \
--comparison "greater_than" --value 500 --email "you@example.com"6) Misconfigured health checks on App Platform
New App Platform deployments commonly fail because health checks hit the wrong port or path, or the app isn’t ready before the first probe. The platform checks your service on its HTTP port (default health-check port falls back to the component’s http_port, often 8080), and you can set an HTTP path (like /health) plus thresholds/timeouts. Align your app’s listen port with the spec and expose a fast 200 OK endpoint.
A minimal Express example that matches a /health check:
import express from "express";
const app = express();
app.get("/health", (_req, res) => res.status(200).send("ok"));
const port = process.env.PORT || 8080; // match App Platform expectation
app.listen(port, () => console.log(`listening on ${port}`));After deploying, adjust health-check settings in the app spec or the console if your service needs more warm-up time.
7) Using SQLite in production
SQLite is fantastic for development and embedded apps, but it allows only one writer at a time per database file. Under load, you’ll hit “database is locked” errors and request pile-ups. For production web workloads, use PostgreSQL or MySQL—preferably Managed Databases so backups, updates, and automated failover are handled for you. Managed PG/MySQL clusters now scale storage independently (in select regions) and include daily backups and HA options.
If you must keep SQLite for a small app, at least enable WAL mode and long busy_timeout, but treat this as a stopgap until you migrate.
8) Treating IPs as disposable (and forgetting reverse DNS)
Destroy a Droplet and you lose its public IP—breaking DNS. Beginners also trip over email deliverability because PTR (reverse DNS) doesn’t match the hostname. Use a Reserved IP so you can reassign the same IP to replacement Droplets, and set the Droplet hostname so reverse DNS is automatically maintained. Reserved IPs are free when attached; unassigned IPv4 reserved IPs are $5/mo due to scarcity.
Reserve and attach via CLI:
# Reserve an IP in the region, then assign to a Droplet
doctl compute reserved-ip create --region fra1
doctl compute reserved-ip list
doctl compute reserved-ip-action assign <RESERVED_IP> <DROPLET_ID>9) Flying blind: no logs or external checks
If you don’t collect logs centrally and don’t watch your endpoints, you’ll find out about issues from users. Turn on DigitalOcean Uptime for public checks and alerts, use Monitoring for server telemetry, and forward application and database logs to a system you can query (e.g., Managed OpenSearch, Datadog, Papertrail, Grafana Loki). App Platform, Kubernetes, and Managed Databases support log forwarding; Droplets can forward via Fluent Bit.
Install Fluent Bit on a Droplet and ship /var/log to your log store; then add alerts on error rates. Keep Uptime checks active to catch SSL expiry and regional latency spikes.
10) Serving all static files from the Droplet
Your web server shouldn’t waste CPU and bandwidth serving big images, JS, CSS, or video. Put assets in DigitalOcean Spaces and enable the built-in CDN. Set correct Cache-Control headers (per-file or bucket defaults) and adjust the edge TTL so assets stay cached. You can also map a custom subdomain (e.g., assets.example.com) to your CDN endpoint.
Upload with cache headers using an S3-compatible tool (Spaces is S3-compatible):
# Example using s3cmd; set your Spaces endpoint in ~/.s3cfg
# Cache assets for 30 days:
s3cmd --add-header='Cache-Control:max-age=2592000,public' \
put ./public/* s3://my-space/You can also change a bucket-wide CDN edge TTL (e.g., 1 day) in Settings, and purge when you deploy breaking changes.
Extras that save you pain later
Use load balancers when you outgrow one Droplet
When CPU or connections spike, add a Load Balancer in front of multiple Droplets. Configure health checks and SSL termination there, and keep backends inside a VPC. This lets you scale horizontally with minimal app changes.
# After you have two+ app Droplets, create a regional load balancer in the console,
# set forwarding 80->80 and 443->443 with SSL termination, and attach your Droplets.
# Keep app servers in the same VPC as the load balancer targets.Keep servers patched automatically
Enable unattended security updates (or schedule manual patch windows). Combine this with snapshots/backups so you can roll back if a package update misbehaves.
sudo apt-get update && sudo apt-get install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgradesPutting it together (a sane first setup)
Create the Droplet in the right region (#3). Add your SSH key and disable password auth (#1). Enable weekly or daily backups and take a first snapshot (#2). Place it in a VPC and attach a Cloud Firewall that only opens 22/80/443 (#4). Point a Reserved IP at it from day one (#8). Ship logs and enable Monitoring + Uptime (#5, #9). Offload assets to Spaces + CDN with proper cache headers (#10). If your app needs a database, pick a Managed PostgreSQL/MySQL cluster instead of SQLite (#7). When traffic grows, add a Load Balancer and a second Droplet (#Extras). Each step removes a class of failure and makes scaling a boring, repeatable exercise.
