Decide what the server will do
Do not begin with a provider comparison. Begin with one sentence: I need this machine to serve a small content website. A static site or a small Next.js application has a very different footprint from a video platform, a busy store or local AI inference. This series assumes one personal website, low initial traffic and no local large-language model.
Write down four facts before opening a checkout page: the software you will run, the expected visitors, whether users upload files, and where most readers live. If those answers are still unclear, choose monthly billing. The flexibility is worth more than a large first-year discount while you are learning.
A sensible starting configuration
For a static site, 1 vCPU and 1 GB RAM can work. For a small application with a database, 2 vCPU and 2–4 GB RAM gives a beginner more breathing room. Choose SSD storage and leave space for logs and backups. This is a starting point, not a universal sizing promise; measure the running site before upgrading.
Use a current LTS release of Ubuntu or Debian unless the project explicitly requires another operating system. Select 64-bit architecture. Do not pay for a control panel yet: learning SSH, Caddy and systemd gives you a setup that is easier to understand and move.
Region, network and cost
Choose a region close to the primary readers, but also check latency from your own network. Read the bandwidth and outbound-traffic rules carefully: a large port speed with a small traffic allowance is not the same as unlimited transfer. Record both the promotional price and the renewal price. Add snapshots, backup storage, tax and domain renewal to the real annual cost.
If you choose a mainland China region, check the provider's current compliance and filing instructions before purchase. Do not assume that a server in every region can publish the same domain immediately.
Checkout checklist
Verify the machine after purchase
The provider console should show a public IP, region, operating system and login method. Copy these into a private note. The address 203.0.113.10 used throughout this series is a documentation example; replace it with your real server IP.
ping -c 4 203.0.113.10
ssh root@203.0.113.10
Some providers block ping, so a failed ping alone does not prove the server is down. The meaningful test is whether SSH connects or the provider console reports a running instance. After login, use uname -a, free -h and df -h to compare the actual machine with the order.
What I learned
My early mistake was buying for an imagined future instead of today's workload. The larger plan did not make the first page easier to publish; it only made the unused months more expensive. I now buy the smallest configuration with enough memory margin, keep billing flexible and upgrade only after the monitoring data gives me a reason.
Finish line
You are ready for the next article when you can answer: where is the server, which Linux version is installed, what is its public IP, what will renewal cost, and can you open an SSH session? Continue with the new-server configuration checklist.