A Pitfall Guide to Buying and Deploying Servers for Indie Developers

The previous post was “follow along on your first server”; this one is “how to choose without getting burned.” The conclusion up front: for a small personal site, specs don't need to be high — 1 CPU and 2GB RAM runs a Next.js app plus a database comfortably. What deserves real thought are three things: region (filing), pricing traps, and backups.

Region: first ask yourself whether you want the ICP filing

A server in a mainland China datacenter means the domain must have an ICP filing before ports 80/443 can serve traffic publicly. Both personal and business filings work; the process is submitting documents and waiting for the regulator's review — days if fast, weeks if slow — and the site can't launch meanwhile. If you can't wait, or your users are overseas anyway, pick Hong Kong, Singapore, or US datacenters: no filing, usable the moment you buy. Where your users are is where the server goes — that's the only hard rule, everything else is preference.

1 CPU 2GB — is it really enough

Plenty to start. A personal site's bottleneck is almost never the CPU — it's memory and bandwidth. 2GB RAM runs the app plus database fine, but builds (npm run build) get tight — a 1GB box may have the system kill big builds outright. Two fixes: add a swap partition for emergencies, or build locally and upload the artifacts. Start bandwidth at the minimum and add more if the site is image/video-heavy; upgrading on demand is always cheaper than going big up front.

Billing traps: read this small print before ordering

• ·Renewal price: many providers offer 10% off the first year and full price on renewal — do your math with the renewal price, not the teaser price
• ·Traffic billing: check whether bandwidth is fixed or metered — metered can get outrageously expensive for image-heavy sites
• ·Snapshots and backups: some providers charge snapshots by capacity; it adds up over time — know the rules before enabling
• ·Pay-as-you-go boxes: remember to shut them down after testing; a few days of neglect can burn a month's budget

Backups: ten times more important than picking a server

Picking the wrong server costs you money or speed at worst; losing data is an instant reset to zero. Only people who've actually lost data know how heavy that sentence is. The minimum backup setup is three things: the database auto-dumped daily, kept 7 days; code in a git repo, not just sitting on the server; environment variables (database passwords, payment keys) stored encrypted in a separate place so you can rebuild immediately if the server dies.

# back up the database daily at 3 AM, keep the last 7 days
0 3 * * * pg_dump -U username dbname > /backup/db-$(date +\%F).sql && find /backup -name "db-*.sql" -mtime +7 -delete

When to upgrade: add resources when it's actually slow

The only time to add specs: when monitoring says they're genuinely insufficient — memory above 80% long-term, pages loading noticeably slower. Don't buy a big machine “in case it goes viral”; you can upgrade after it does — scaling a cloud server is just a reboot. The money you save is better spent on backups and domain renewals.

Pay-as-you-go vs. annual/monthly plans: when to pick which

Annual/monthly plans are pay-first, discounted, and suit sites that will run long-term — your production site gets one of these. Pay-as-you-go bills by the hour, costs more, but spins up and down anytime — good for short tests, like checking latency in a region or running a quick load test. One trap: with pay-as-you-go, “powered off” does not mean “not billed” — many providers keep charging for the disk and IP until you “release” the instance. After testing, always confirm in the console that the machine shows as “released,” or a few days of sitting there can burn a month's budget.

How to do the math: annual/monthly discounts are usually 30–50% off pay-as-you-go rates. If a box will run more than three months, go annual/monthly; if unsure how long it'll run, go pay-as-you-go for a week, then switch to annual/monthly once it's smooth. Don't agonize over “what if I stop using it” — the whole point of cloud servers is that you can switch anytime; buying wrong costs you a week's money at most.

Student boxes and lightweight servers: are they enough

Enough to start. Every provider has lightweight servers — 1 CPU and 2GB for a couple hundred RMB a year, with a fixed traffic allowance bundled, very friendly to personal sites. Check two things before buying: how overage traffic is billed once the allowance runs out — pay-as-you-go deductions or throttling (image-heavy sites should do the math); and lightweight boxes have fixed bandwidth, so extreme peaks will choke — but a personal site will basically never hit that ceiling. If you do, congratulations — you have traffic.

When they're not enough: memory above 80% long-term, pages loading noticeably slower, builds getting killed by the system. When that day comes, upgrade: a few clicks in the console and one reboot, your data is intact. Buy small first; the savings go to renewing the domain and doing backups — no loss.

Buying the domain and server separately: pros and cons

The upside of separating: register the domain at a cheap registrar, buy the server from whichever provider is the best deal, no lock-in. If the server's price jumps or service degrades, move the whole site — one DNS change and users never notice. The upside of buying together is convenience: one dashboard for everything, sometimes a free first-year domain — good if you hate hassle.

My advice: separate them. A domain is an asset — pick a solid registrar, hold it long-term, turn on auto-renewal. An expired domain snatched by someone else costs a fortune to redeem; don't step in that pit. A server is a consumable — go with whichever is cheap and good, and since your data is backed up and your code is in git, moving is a half-day job. Assets and consumables get different strategies; that's what separates veterans from beginners.

Database: self-host or managed

The previous post had you install PostgreSQL — that's self-hosting. Providers also sell managed databases (RDS): pricier, but backups, replication, and monitoring are done for you. Self-hosting is cheap; you write your own backup cron. For a personal site, self-hosting plus daily automatic backups is completely fine, and the money saved each month covers the domain renewal. When your data matters enough that “losing an hour hurts,” switch to managed — by then you can afford it.

Renewals and expiry: the most overlooked trap

Buying a server isn't a one-and-done deal. Three expiries to watch: domain renewal (getting your expired domain snatched is the worst loss — turn on auto-renewal and keep the card funded), server renewal (annual/monthly plans that lapse will shut down — set a reminder a week ahead), SSL certificates (all auto-renew now, but glance each quarter to confirm they renewed). Three recurring reminders on your phone calendar cost you five minutes a year and dodge the dumbest failures.

Bandwidth: fixed or metered

Fixed bandwidth buys a peak, e.g. 5 Mbps costs the same for the month whether you use it fully or not; metered billing charges actual usage — you pay for what you use. For image- and video-heavy sites, estimate monthly traffic first: daily visits × average page size × 30 days. If the number is small, go metered; big image sites go fixed. When unsure, start fixed and add more later — adding bandwidth is a few console clicks; shrinking it is not as painless.

Snapshots: check the price before buying

Snapshots (full-machine backups) are handy — one-click rollback when you break the system. But watch out: many providers charge snapshots by capacity, and they add up over a month. The habit: take one before a big change, delete the old one once the change is confirmed fine. Snapshots are “undo medicine,” not “save files” — don't hoard dozens. Also, snapshots don't replace database backups; the daily database dump is a separate job, still required.

Multiple servers: when do you need a second one

One server goes a long way: app plus database together handles a personal site up to thousands of daily active users. When do you need a second box? When the database gets slow enough to hurt the site — split the database out; or when you need read/write splitting or primary-replica backups. Remember: those are post-traffic problems. Don't design a “high-availability architecture” before you have users. Premature optimization is the root of all evil — server architecture included.

IPv6: do you need it

Some providers include an IPv6 address, some charge extra. For a personal site it's optional: mainland users are basically all IPv4, some overseas networks use IPv6. Don't pay extra for it or switch providers over it. If you do use it, remember to configure the firewall rules for IPv6 separately — many people enable IPv6 and forget the firewall, leaving a back door open.

Support: who to call when things break

Providers all have ticket systems — use tickets for problems, don't count on phone calls. When filing, paste three things: the instance ID, the original error text, and how far you got. The more complete the info, the faster the fix. Know the split: server unreachable, console won't open — that's the provider; site errors, code problems — that's on you, a ticket won't help. Figure out whose problem it is first, then find the right person.