📝 Written ● Beginner Updated 2026-05-13

Buy a server from DigitalOcean

A DigitalOcean droplet is the most popular shape of "small Linux server you rent by the hour" — predictable pricing, simple onboarding, the right defaults for someone who just wants a box on the internet. Five dollars a month gets you something you can do real work on.

Before deciding which VPS to buy, decide whether you actually need a VPS at all. Most things that used to require renting a Linux box no longer do. A static site goes on Vercel, Netlify, or Cloudflare Pages — better, cheaper, faster than a $5 droplet running Nginx. A backend API in a managed runtime (Vercel Functions, Cloudflare Workers, Fly.io machines) sidesteps most of the maintenance work a VPS demands. Even a database often belongs at Supabase, Neon, or PlanetScale rather than self-managed.

A VPS becomes the right answer when you want full root, when you want to install software the managed platforms don't support, when costs are sensitive at scale, or when you want to understand what your software actually does on a real machine. None of these are wrong reasons — they're just different from "I need a place for my Next.js site," which is a worse use for a droplet than for a managed host.

If you've decided a VPS is what you want, DigitalOcean is the friendliest of the credible choices. The UI is calm, the documentation is genuinely good, the cheapest plan ($5/month for 1GB RAM, 1 vCPU, 25GB disk) is real and usable, and the company has been around long enough that the platform isn't going anywhere. The trade-off is that DigitalOcean is no longer the cheapest VPS per dollar — Hetzner offers more for less, especially in Europe. The DO premium is for the polish and the docs.

What you'll learn

Whether to buy a VPS at all (vs. managed hosting)
Picking a droplet plan that fits your workload
Adding SSH keys to your account before creating the droplet
The first ten minutes — firewall, non-root user, updates
When to scale up vs. when to scale out

Step 1: Decide on a plan

Basic droplets are enough for almost everything

DO has many droplet families; ignore most of them. The two you'll touch:

Basic. Regular intel or AMD CPU, predictable pricing. $5/month for 1GB/1vCPU/25GB. $12/month for 2GB/1vCPU/50GB. Right for small apps, hobby projects, learning environments. The $5 tier is real — many production indie projects run on it.
Premium AMD / Intel. Same shape, faster CPUs, ~$1–2 more per tier. Right when CPU-bound workloads matter. Don't bother unless you've measured.

"CPU-Optimized," "Memory-Optimized," "GPU" droplets exist for specific cases (heavy compute, in-memory caches, ML inference). Skip on first server.

Step 2: Add an SSH key first

Before creating the droplet, not after

Generate an SSH key pair on your Mac if you don't have one:

ssh-keygen -t ed25519 -C "[email protected]"
# Press enter for default path; set a passphrase or leave blank

This creates ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public). Copy the public key:

pbcopy < ~/.ssh/id_ed25519.pub

In the DO dashboard, go to Settings → Security → SSH Keys → Add SSH Key. Paste, name it ("my-mac"), save. From now on, every droplet you create can be configured to accept this key — meaning passwordless, secure access.

Why SSH keys instead of a password: bots constantly scan the internet for SSH servers and try common passwords. SSH keys aren't guessable; the brute-force attack surface goes away. Once you've used key auth once, password auth feels archaic.

Step 3: Create the droplet

Image, region, size, key, name

Click Create → Droplets. Make five choices:

Image: Ubuntu LTS (currently 24.04). Familiar, well-documented, lots of community recipes work without translation.
Region: closest to your users. For a personal project, closest to you. NYC3, SFO3, AMS3, FRA1, SGP1 are common.
Size: Basic $5/mo to start. You can resize later (well, mostly — disk shrinks aren't supported).
Authentication: SSH Key (pick the one you added in Step 2). NOT password.
Hostname: something memorable — web-1, blog-prod, anything. You'll see this in your terminal prompt.

Click Create Droplet. After 60 seconds the droplet is live and you'll see its IPv4 address in the dashboard.

Step 4: SSH in

The first connection

From your Mac terminal:

ssh root@<droplet-ip>

The first time, SSH asks if you trust the host fingerprint — type yes. You're now on the droplet's root shell. Running uname -a should print Linux + the Ubuntu version. The droplet is yours.

Step 5: First-ten-minutes hardening

Three things to do immediately

Before you install anything else:

# Update package lists and upgrade what's installed
apt update && apt upgrade -y

# Create a non-root user (replace 'deploy' with your preferred name)
adduser deploy
usermod -aG sudo deploy

# Copy your SSH key to the new user so you can ssh in directly
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

# Turn on the firewall, allow SSH only
ufw allow OpenSSH
ufw enable

Test that the new user works by opening a second terminal and running ssh deploy@<droplet-ip>. Once you confirm that works, edit /etc/ssh/sshd_config to set PermitRootLogin no and restart sshd (systemctl restart sshd). Now root can't log in at all; everything goes through your deploy user, which has to type sudo for privileged operations.

You can also enable additional firewall rules as you install services (ufw allow http, ufw allow https).

Don't disable root login until you've confirmed your non-root user works. If you misconfigure and lock out both, you're in the DO recovery console — annoying but survivable. The "two terminals open at once" trick prevents this entirely.

Step 6: Point your domain

A record at your DNS provider

At your registrar (or wherever your DNS lives), add an A record:

Name: @ (root) or a subdomain like app
Value: your droplet's IPv4 address
TTL: 3600 (default is fine)

See Connect your domain to a server for the full DNS walk. After propagation (usually minutes), yourdomain.com resolves to your droplet.

Then install Nginx or Caddy on the droplet, set up Let's Encrypt for HTTPS, and you have a real public web server.

Step 7: When to scale up vs. out

Vertical first, horizontal later

Scaling up (a bigger droplet) is one click — power off, resize, power on. Storage grows but doesn't shrink. Useful when one process is CPU- or memory-bound and could just use more.

Scaling out (multiple droplets behind a load balancer) is much more work but the right move when one machine isn't enough or when you want redundancy. DO's managed load balancer is a separate product ($12/mo) that fronts multiple droplets.

For 95% of personal projects, "scale up the single droplet until it stops being economical, then think about anything else" is correct.

Snapshots are your save state. Before doing anything risky (upgrading a major package, changing kernel, etc.), take a snapshot from the droplet's Snapshots tab. It costs a small monthly fee while it exists, but you can restore from it if you brick the machine.