Every scraping job eventually runs into the same wall: the box is either too small to keep up with the queue, or too big for what the job actually needs. We get asked constantly which VPS for web scraping to provision for a given crawl — a thousand product pages a day is a different animal than a hundred thousand JS-rendered listings an hour. This is the spec matrix we actually use when a client asks us to size one.
Why VPS Sizing for Scraping Isn't Just "More Cores"
Scraping load doesn't map to a single resource the way a lot of workloads do. Plain HTTP fetches are network- and connection-bound — a single vCPU comfortably handles high volumes of small requests, and the bottleneck is almost always target-site rate limits or your own concurrency settings, not the box. Headless browser scraping (Playwright, Puppeteer, Crawlee-driven crawls) is a different profile entirely: each browser context holds its own render tree in RAM, and CPU gets burned on JS execution, layout, and screenshotting — not just the wire transfer. Storage matters too, mostly for dedup/queue state (Redis, SQLite, or a local Postgres tracking visited URLs) and for output — NVMe keeps write-heavy crawl logs and cached responses from becoming the bottleneck once a job passes a few million rows.
Choosing a VPS for Web Scraping by Workload Type
Here's how we map our VPS tiers to scraping workloads in practice:
| Tier | RAM / vCPU / Disk | Price | Scraping fit |
|---|---|---|---|
| VPS I | 2GB / 1 vCPU / 40GB NVMe | €4/mo | Plain HTTP scraping, API polling, RSS/sitemap crawlers, curl/requests/httpx-based jobs |
| VPS II | 4GB / 2 vCPU / 80GB NVMe | €6/mo | Light headless work — a couple of concurrent Playwright/Crawlee contexts, moderate HTTP concurrency |
| VPS III | 8GB / 2 vCPU / 120GB NVMe | €10/mo | A handful of concurrent headless contexts with room for parsing/dedup processes |
| VPS IV | 8GB / 2 vCPU / 120GB NVMe | €16/mo | Same footprint, higher-priority tier for jobs needing steadier CPU access under load |
| VPS V | 16GB / 4 vCPU / 200GB NVMe | €30/mo | Multiple headless browser instances running in parallel, larger dedup/queue tables |
| VPS VI | 32GB / 6 vCPU / 400GB NVMe | €58/mo | Sustained multi-instance crawling — many headless contexts, heavier proxy rotation logic |
All tiers ship with 1 Gbps unmetered symmetric bandwidth, NVMe storage, root SSH, and both IPv4 and IPv6 — hourly billing means you can size up for a burst crawl and scale back down the same day.
Plain HTTP Scraping: VPS I Is Genuinely Enough
If your scraper is issuing HTTP requests and parsing HTML/JSON with something like requests, httpx, or Scrapy without a browser engine, you don't need much iron. A single vCPU handles a high volume of small requests without strain — the limiting factor is almost always target-site rate limits or your own concurrency settings, not the box. VPS I at €4/mo (billed to the second at €0.0056/hr) is the right starting point for sitemap crawls, price monitors, and API-polling jobs. Don't over-provision here; the money is better spent on more IPs or more instances running in parallel than on a bigger single box.
Headless Scraping: Where Mid Tiers Earn Their Keep
The moment a target site needs JS execution to render content — infinite scroll, client-side routing, anti-bot challenges that gate on browser fingerprints — you're running a real browser engine per session. This is headless scraping server hosting territory, and RAM becomes the limiting factor before CPU does. Each Chromium context under Playwright or Puppeteer is memory-hungry rather than CPU-hungry — budget generously per context, and more still if you're capturing screenshots or full-page/DOM snapshots. VPS III and VPS IV (8GB/2 vCPU) comfortably run a handful of concurrent contexts with Crawlee's built-in autoscaling; VPS V (16GB/4 vCPU) has meaningfully more headroom for running several contexts in parallel before memory, not CPU, becomes the constraint. Watch memory when you're deciding whether to scale up a tier.
Sustained Multi-Instance Crawling: VPS VI and the Dedicated Line
VPS VI (32GB/6 vCPU/400GB, €58/mo) is our ceiling for VPS-class scraping — it's built for sustained, multi-instance crawls running around the clock, not just a burst job. Beyond that, the math changes. If you're running many headless instances continuously, coordinating a distributed crawl across multiple worker nodes, or processing scraped output through a heavy parsing/ML pipeline on the same box, you've outgrown shared-tenancy VPS economics. That's the point to move to a dedicated server — full physical cores with no noisy-neighbor variance, and headroom to run the crawl orchestrator, the browser pool, and the storage layer on one machine instead of juggling several VPS instances.
Why Unmetered Symmetric Bandwidth Matters Here
Scraping is asymmetric by nature on most hosting plans — you're pulling far more data down than you push up — and metered bandwidth tiers punish exactly that pattern. An unmetered bandwidth scraping VPS setup means a crawl that suddenly needs to pull tens of thousands of pages overnight doesn't trigger an overage bill or a throttle. All our VPS tiers run 1 Gbps unmetered symmetric, so scrape volume scales with what your target sites and your own rate limiting allow, not with a bandwidth cap we've imposed. That matters most on image-heavy or PDF-heavy crawls where per-page payload size adds up fast.
Dedicated IPv4 and Why It's Not Optional for Serious Crawls
Every instance gets its own dedicated IPv4 and IPv6 address — no shared-IP roulette where another tenant's aggressive crawler gets your IP rate-limited or blocklisted before you've sent a single request. For a dedicated IP VPS scraping setup, that isolation is the whole point: if you're running several scrapers against several targets, spreading them across separate instances with separate IPs keeps one target's rate-limit response from bleeding into another job. It also makes IP reputation something you control directly, rather than inheriting someone else's history.
A Note on What You're Scraping
If the data you're collecting includes personal information — names, emails, pricing tied to individual accounts, anything that touches EU residents — where that data lands and how it's processed matters as much as the crawler's throughput. Worth building that into the plan from the start rather than retrofitting it once a pipeline is already running, especially if scraped records get stored or processed rather than just aggregated.
How Noded Can Help
We run our own AS60982 network with 1 Gbps unmetered symmetric bandwidth on every tier, so a scraping job that spikes overnight doesn't turn into a surprise invoice or a throttled connection. Spin up a VPS sized to today's crawl, billed hourly to the second, and resize up or down as the job changes shape — median deploy time is 47 seconds, so testing a bigger tier costs you a minute, not an afternoon. Every instance ships with free 1 Tbps DDoS protection, root access, and its own IPv4/IPv6, and when a crawl outgrows VPS-class resources entirely, our dedicated servers are the next step up on the same network.
FAQ
What VPS specs do I need for basic web scraping?
For plain HTTP scraping without a headless browser — requests, httpx, Scrapy-style crawlers — a 1 vCPU/2GB instance like VPS I is enough. The bottleneck is almost always target-site rate limits, not local CPU or RAM.
How much RAM does Playwright or Crawlee need per scraping instance?
Each headless browser context is memory-hungry rather than CPU-hungry — budget generously per context, more if you're capturing screenshots or full-page snapshots. An 8GB instance comfortably runs a handful of concurrent contexts; a 16GB instance has room for noticeably more before memory, not CPU, becomes the limit.
Do I need a dedicated IP for web scraping?
It's strongly recommended once you're running more than one scraper or targeting rate-limit-sensitive sites. A shared IP means another tenant's crawl behavior can get your IP flagged before you've sent a request. A dedicated IPv4 per instance keeps your reputation isolated and under your control.
When should I move from VPS to a dedicated server for scraping?
When you're running many headless browser instances continuously, orchestrating a distributed crawl across multiple workers, or running heavy parsing/storage on the same box as the crawler, VPS-class shared tenancy stops making economic sense. A dedicated server gives full physical cores with no noisy-neighbor variance for that scale of sustained crawling.
Why does bandwidth need to be unmetered for scraping workloads?
Scraping is download-heavy and bursty — a crawl can pull tens of thousands of pages in a short window. Metered bandwidth tiers either throttle that burst or bill it as overage. Unmetered symmetric bandwidth means scrape volume is limited by your own rate limiting and target-site rules, not by a hosting cap.