Create the Droplet
Plan cost, region, and size
Choose the smallest useful server near its users and understand which resources keep billing until you remove them.
Pick the server for the workload you have today, not the one you hope to have next year. A small site or a learning project runs fine on a Basic shared-CPU Droplet. Dedicated CPU or a bigger machine make sense only after measurements show sustained CPU pressure, memory pressure or slow disk I/O.
Don’t size from traffic alone. A quiet app that keeps a big process in memory can need more RAM than a busy static site. Memory is usually the first thing a small Droplet runs out of.
Pick the region
Choose the region closest to the people and services that exchange the most data with the app. If you use a managed database, put it in the same region as the Droplet. Private traffic stays on the local network and latency stays low.
Regions are hard to change later. Resizing a Droplet is a few clicks. Moving to another region means creating a new server, copying the state, testing it and moving traffic. So spend a minute on this choice now.
Write down the plan
Before you click Create, write these down:
- the region
- how much RAM, CPU and disk you expect to need
- whether you will enable backups and improved monitoring
- the monthly estimate the control panel shows you
- any extra volumes, snapshots or reserved IP addresses
Treat the control panel estimate as the truth. Prices and plan names change, so a number copied from a two-year-old tutorial is not reliable. I’m not quoting prices here for the same reason.
What keeps billing
A powered-off Droplet still costs money. It reserves CPU, RAM and disk, so DigitalOcean keeps charging for it. Billing stops only when you destroy it.
Backups, snapshots, volumes and reserved IPs are separate resources with their own bills. They can keep charging you after the Droplet is gone. We’ll come back to this in the last lesson, when we retire the server.
Start small, measure, then resize
Starting too big wastes money every month. Starting too small without monitoring gives you crashes with no explanation. The approach I use is to start with a reasonable minimum, turn on metrics, and resize only when I can point at the resource that ran out.
Try this now: write a one-paragraph capacity guess for the notes application we’ll deploy in this course. Include the expected number of users, the persistent data it stores, the region, the plan category you’d start with, and the metric that would make you resize. Later we’ll compare that guess with real numbers from the server.
Lesson completed