Set Up Your First Server on Purpose

Why this matters

Most teams click 'create droplet' and accept the defaults, then discover three months later they're on the wrong instance family, the wrong region, the wrong disk type, or running on a kernel they can't update. A few minutes spent at provisioning time — picking the region close to your users, the instance type matched to your workload (CPU-bound vs memory-bound vs network-bound), and a base image you understand — saves weeks of migration pain later. This isn't premature optimization; it's the difference between 'I'll redo the box on Saturday' and 'I have to migrate prod next quarter.'

Demo

Sizing rule of thumb for a CRUD API at Day 0: 1 vCPU, 2 GB RAM, 25 GB SSD, in the same region as your DB. You can serve a few hundred concurrent users on this — modern languages can push 1k+ req/sec on a single core if the DB keeps up. Pick the region by where your users (or your DB) are. Pick an instance family marked 'general purpose' (DigitalOcean: regular; AWS: t-class; GCP: e2-medium). Pick an SSD-backed disk, never spinning. And pin your base image (Ubuntu 24.04 LTS, Debian 12) — don't 'use the latest'.

Try it yourself

1. Look at your current/last VM: what region is it in, what's the instance family, what disk type, what kernel/OS version? Document it in a README. You should know this without checking.
2. Pick a region using a real signal: where your users actually are (check Google Analytics country breakdown) OR where your DB lives. Don't pick the cheapest region if your users are 200ms away.
3. Run curl -s http://ipinfo.io/json | jq from your VM. Confirm region and AS-number match what you provisioned.
4. Set up unattended-upgrades. Run cat /var/log/unattended-upgrades/unattended-upgrades.log after a week — you should see security patches applied automatically.

References

• AWS EC2 instance types — overview
• DigitalOcean droplet types
• Cloudflare — choosing a region