The best VPS for web scraping

A VPS gives a crawler the three things shared hosting and serverless functions cannot: dedicated resources, persistent state and unrestricted OS control. Because each tier is KVM with allocated vCPU and RAM rather than a shared container, a long-running crawl will not get throttled the moment a neighbour spikes. You get root, so you install whatever your job needs — Python with Scrapy, Node with Crawlee, a full headless Chromium under Playwright, your own queue and database — and you keep it running on a schedule with cron or systemd timers.

Persistence matters more than people expect. A scraper that maintains its own request queue, deduplication store and partial results survives restarts and resumes cleanly, which is far more reliable than stateless function invocations that reset every run. Unlimited traffic on every tier means a large crawl will not hit a bandwidth overage mid-job, and a dedicated NVMe disk keeps your local cache, parsed output and any embedded database fast. If you are new to provisioning one, the docs walk through first boot and SSH access.

Match the tier to what your crawler actually does, not to the size of the target site. The deciding factor is whether you render JavaScript.

• Light, text-only scraping — HTML fetches with requests, httpx or Scrapy, parsing with lxml or BeautifulSoup. This is memory-light and IO-bound; the Cub (1 vCPU / 2 GB / 40 GB) or Scout (2 / 4 / 70) handle it comfortably, even at high concurrency.
• JavaScript-rendering and headless browsers — Playwright, Puppeteer or Selenium driving headless Chromium. Each browser context can consume 300-700 MB, so plan for at least 4 GB RAM and 2 or more vCPU. The Runner (3 / 6 / 100) suits a few concurrent browsers; the Hunter (4 / 8 / 140) gives real headroom for a pool of them.
• Heavy, parallel crawls — large frontier, many simultaneous renders, an in-process database. Step to the Alpha (6 / 12 / 200) or higher so the OOM killer never reaps a worker mid-run.

Headless Chromium is almost always the bottleneck. If your scraper does not need a real browser, run a plain HTTP client and you will get several times the throughput on the same tier.

Most budget-cloud IP ranges arrive pre-blacklisted. They have been used for spam, abuse and prior scraping, so anti-bot systems and DNS blacklists already distrust them — which means more captchas, more 403 and 429 responses, and outright blocks before your crawler does anything wrong. The IP's reputation, not your behaviour, is what gets you challenged.

We screen and allocate clean IP space, and every server ships with one dedicated IPv4 plus an IPv6 /64. A clean, non-recycled address means fewer interstitial challenges and a higher share of pages that simply load. You do not have to take that on faith: before or after you deploy, run your IP through Spamhaus, AbuseIPDB or Cisco Talos. Our guide to checking if an IP is blacklisted walks through it, and if you ever land on a flagged address you can request a swap through the control panel.

A VPS and a proxy network solve different problems, and confusing them wastes money. The VPS is where your scraper runs — the compute, the queue, the parsing, the storage. A proxy is the exit IP your requests appear to come from. A single VPS has one clean dedicated IP, which is excellent for moderate-volume crawling against sites that rate-limit per IP rather than blanket-block.

You add rotating proxies on top of the VPS once a single IP is no longer enough: high request volume that would trip per-IP rate limits, geo-targeted data that must appear to originate from specific countries, or aggressive anti-bot defences that block any IP making more than a handful of requests. In that architecture the VPS still does all the work and orchestrates the rotation; the proxies only change the apparent source address. For most projects, start with the clean VPS IP alone, measure your block rate, and add proxies only when the data proves you need them.

Deploy a recent Ubuntu LTS (we also offer Debian, AlmaLinux, Rocky, Fedora, Arch, Alpine and FreeBSD) and build from there:

• Scrapy — the most efficient choice for large text crawls. Its async engine sustains high concurrency on modest RAM; tune CONCURRENT_REQUESTS, DOWNLOAD_DELAY and AUTOTHROTTLE to stay polite and avoid self-inflicted blocks.
• Playwright or Crawlee — reach for these only when the data is behind JavaScript. Run headless Chromium with --no-sandbox in a container or a constrained user, and cap the number of concurrent browser contexts to your RAM budget so the OS does not start swapping.

Operational hygiene keeps long jobs healthy: send headless Chrome's user-data directory and your output to the NVMe disk, not a network mount; run the crawler under systemd so it restarts on failure; and watch memory with htop during the first full run, because a leaking browser pool is the most common cause of a stalled crawl. Pay for any of it without ID through our crypto VPS checkout.

Scraping is a tool, and the legality lives in how you use it. Collecting publicly accessible data within a target site's terms of service and the applicable law is a legitimate, common use of a server. Hammering a site until it falls over, circumventing authentication, or harvesting personal data in breach of privacy law is not — and that is on you, not the infrastructure.

Our policy is straightforward. We run an offshore, court-order-only operational stance: routine complaints are handled as policy rather than automatic takedowns, and we act on valid court orders in the server's jurisdiction. That is operational policy, not legal immunity — we never claim a server is untouchable. There is also a hard floor that applies to every account with no exceptions: no CSAM, no weapons trafficking, no terrorism. Read the full acceptable-use policy before you scale up a crawl.

For most scraping projects the choice is simple. Text-only crawlers run happily on the Cub or Scout; anything driving headless browsers wants the Runner or Hunter for the RAM and vCPU that Chromium demands; large parallel jobs scale into the Alpha and above. Every tier is all-NVMe KVM with a clean dedicated IP and unlimited traffic, so a heavy crawl never meets a bandwidth cap, and you can resize as your workload grows.

Deployment takes about 60 seconds after payment confirms, with no setup fee and honest month-to-month pricing — annual prepay gives you two months free. Pay with Monero, BTC, ETH, LTC, USDT or USDC-on-Base; we are no-KYC, so there is no ID and no document upload, only an email for credential delivery. That makes us private, not anonymous: real anonymity also depends on your own payment and network hygiene, including where you fund the wallet you pay from.