Buy a server

A lot of people hear "go live" and immediately think "I need to buy a server." Honestly though — your project probably doesn't need one. This guide first helps you decide whether to buy, then shows you how to choose if you actually do.

Do you actually need a server?

Most vibe-coded projects can ship their first version without ever touching a server. Ask yourself first: can you publish a simpler way?

So when do you really need your own server?

• Long-running processes: background workers, queue consumers, scheduled jobs, scrapers — these are awkward or expensive on serverless.
• WebSockets / long-lived connections at scale: chat, real-time collaboration, game backends. Once connection counts climb, serverless connection-duration and concurrency limits get in the way.
• Custom system dependencies: a specific version of a system library, ffmpeg, a headless browser, GPU drivers, or a tool that only ships a Linux binary.
• Self-hosting databases / tooling: running your own PostgreSQL, Redis, MinIO, n8n, or open-source tools, keeping control of your data and cost.
• Full control: your own nginx, your own kernel tuning, install anything you want, no platform black box.
• Cost at scale: past a certain traffic level, usage-based PaaS / serverless billing ends up costing more than one fixed-price VPS.

If any of those describes you, read on — it's time to buy a server.

VPS vs dedicated vs cloud

These three terms get used interchangeably, but they differ underneath. In short: the difference is whether resources are shared with others, and whether you can scale elastically.

A few key concepts:

• Shared vs dedicated: a VPS and a cloud instance share the physical box with other tenants — cheaper, but you can occasionally feel a "noisy neighbor." A dedicated server is the whole building to yourself — pricier but more consistent.
• What a "cloud instance" actually is: still a virtual machine, but running on a platform like AWS / GCP / Azure with a whole suite of services around it — snapshots, images, load balancers, object storage, autoscaling. You can launch one with a single API call and delete it when done.
• For beginners: 90% of the time what you want is a VPS or an entry-level cloud instance. Skip dedicated servers for now.

How much to buy

The most common beginner mistake is buying a big box up front. A small project needs shockingly little — and nearly every VPS lets you resize online later, so start small and grow is always the right call.

How to read each spec:

• vCPU (virtual cores): 1 core is enough to start. Web apps are mostly IO-bound, not CPU-bound. Only reach for more cores when you compile, transcode, or run AI inference.
• RAM: this is what runs out first on a small server. 1 GB works, but running app + database + a build at once gets tight; 2 GB is a more comfortable starting point. When memory runs out, the OOM killer starts killing processes.
• Disk: prefer SSD / NVMe, never spinning disks. NVMe is faster than plain SSD, noticeably so for databases and read/write-heavy workloads. 25–40 GB fits the OS + your app + a modest database. Watch logs and uploads for growth.
• Bandwidth vs monthly transfer quota: these two get confused constantly.
  • Bandwidth: how wide the pipe is, e.g. a 1 Gbps port — it sets instantaneous speed.
  • Transfer quota: how much water can flow in a month, e.g. 1 TB of outbound transfer per month.
  • Most cheap VPS plans sell "uncapped port speed + X TB of transfer per month."

Region & latency

Where your server lives directly determines how fast it feels for your users. The rule is simple: closer to your main users is better.

• Users mostly in Asia → pick a Singapore / Tokyo / Hong Kong region; users in the US/EU → pick a local region.
• A trans-oceanic round trip easily costs 150–300 ms, and that adds up across multiple requests.
• Test latency before you buy: many providers offer a "looking-glass" IP or a test file. Measure with ping and mtr:

# Measure latency (look at avg / jitter)
ping -c 20 test-ip-or-host

# See per-hop loss and latency to find the slow segment
mtr -rwc 50 test-ip-or-host

• Hand static assets to a CDN: even if the server is far away, putting images, JS, CSS, and fonts behind a CDN like Cloudflare lets users fetch from the nearest edge node, dropping latency immediately. Only dynamic requests hit your origin. See Set up Cloudflare.

Billing models

The "$5/mo" sticker price is often not what you'll actually pay. Understanding billing keeps you out of trouble.

• Hourly vs monthly: cloud instances usually bill hourly (you pay for the hours you run), great for throwaway tests. VPS plans are usually monthly. Use hourly instances for short experiments, monthly plans for anything long-running.
• Reserved / committed discounts: long-term use can buy a "reserved instance" or annual term, typically saving 20%–60%. But don't lock into a year for a project you haven't validated — run it monthly until it's stable, then consider committing.
• The hidden cost behind "from $X/mo": the sticker is usually the bare box. On top you may pay for:
  • Backups / snapshots: automated backups are often billed separately (e.g. ~20% of the box price).
  • Extra transfer: see overage billing above.
  • A dedicated / additional IP: some providers charge for IPv4 addresses.
  • Load balancers, object storage, managed databases, and other add-ons.

Next

Once you've decided whether to buy, and understood specs and billing, the next step is actually picking a provider:

The moment a server boots it's exposed to the public internet, so do basic hardening right away — don't wait to get scanned.