Best VPS for Web Scraping in 2026: I Got Suspended by 3 Providers Before Finding What Actually Works

The Suspension Story: What Happened in 48 Hours

January 2026. I deployed an identical Playwright scraper on five VPS providers, all targeting the same publicly accessible product catalog. Same rate limits (one page every 2 seconds), same rotating user agents, same robots.txt compliance. No login bypassing, no CAPTCHA solving, no personal data. Just reading public listings the way any price comparison engine does.

Here is the timeline:

• Hour 6: Provider #1 (I will name them below) sent a "Terms of Service Violation" email. My VPS was still running, but the email stated automated data collection violated their AUP and continued activity would result in termination.
• Hour 14: Provider #2 suspended my instance without warning. No email. No ticket. Just a dashboard notification saying "Your droplet has been powered off due to a potential TOS violation." I had to submit a support ticket to get it reinstated, which took 9 hours.
• Hour 31: Provider #3 sent a forwarded abuse complaint from the target site's hosting company. Their response: "Please resolve this within 24 hours or we will suspend your account." Technically a warning, but the clock was ticking.
• Hour 48: Contabo and Hetzner were still scraping without a single notification. No warnings, no abuse forwards, nothing. They just... let the server do what I told it to do.

The lesson: TOS compliance is the single most important spec for a scraping VPS. You can have 32TB of bandwidth and 16GB of RAM, but if your provider kills your instance after 6 hours, none of those specs matter.

TOS Breakdown: What Each Provider Actually Allows

I read all five AUPs — the actual legal documents, not the marketing pages. Here is what they say about automated data collection:

Every provider here tolerates small-scale scraping. The differences emerge at scale — thousands of pages per hour, abuse complaints from target site admins. That is the moment that separates scraping-friendly providers from the rest.

The Residential vs Datacenter IP Problem (And Why Your VPS IP Is Already Flagged)

Something I wish someone had told me before spending $200 on VPS instances trying to scrape Amazon: your datacenter IP is already in a database. Cloudflare Bot Management, DataDome, and PerimeterX maintain lists of every IP range belonging to every major VPS provider. Your request arrives, the system checks the IP against the database, and says: "Datacenter IP. Apply strict verification." CAPTCHAs, JavaScript challenges, or a flat 403 — before it even looks at your user agent.

For any target with serious anti-bot protection, a VPS alone is not enough. You need one of two strategies:

• Strategy A — Residential proxy overlay: Your scraper runs on the VPS (for compute and scheduling), but routes requests through a residential proxy service like Bright Data, Oxylabs, or SmartProxy. These services maintain pools of residential IPs and charge $5-15/GB. Expensive, but necessary for sites like Amazon, LinkedIn, or any site behind Cloudflare Bot Management.
• Strategy B — Datacenter IP diversity: For sites without aggressive anti-bot protection (most small-to-mid-size sites), distributing requests across multiple datacenter IPs in different regions avoids triggering rate limits. This is where Vultr's 9 US datacenter locations become valuable — 9 IPs in 9 cities looks very different from 9 requests from the same IP.

I use Strategy B for 80% of my projects. Residential proxies only when a target specifically blocks datacenter IPs. At $10/GB versus free VPS bandwidth, that distinction saves hundreds per month.

#1. Contabo — The Scraper's Safe Haven ($6.99/mo)

Contabo is where my Puppeteer farm lives, and it has been there for eight months. The $6.99/month plan: 8GB RAM, 4 vCPUs, 200GB SSD, 32TB bandwidth. That bandwidth number in context — scraping pages averaging 500KB at one per second, 24/7, consumes 1.3TB per month. You would need 24 concurrent scrapers running non-stop to approach the 32TB ceiling.

The reason Contabo tops this list is not the specs. It is the attitude. I submitted a support ticket asking directly: "Is automated web scraping of publicly available data permitted under your AUP?" The response: "We do not restrict how you use your server as long as you are not violating laws or generating abuse complaints that we cannot resolve." No hedging. No pointing to a vague clause about "automated access."

I ran 18 concurrent Puppeteer instances on this plan. Memory hovered at 6.8GB — tight but stable, zero OOM kills over 14 days. The CPU (benchmark 3200, lowest on this list) was the bottleneck at 85-95% utilization during JavaScript rendering, but the 2-second crawl delay between pages gave it time to catch up.

My Puppeteer Config on Contabo 8GB

// Optimized for Contabo Cloud VPS M (8GB RAM)
const browser = await puppeteer.launch({
  headless: 'new',
  args: [
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--disable-dev-shm-usage',   // Critical on VPS
    '--disable-gpu',
    '--no-first-run',
    '--no-zygote',
    '--disable-extensions',
    '--disable-background-networking',
    '--metrics-recording-only',  // Reduce memory overhead
    '--mute-audio',
  ]
});
// Max 18 concurrent pages with this config
// Memory per instance: ~350MB average
// Total footprint: ~6.3GB + OS overhead

Contabo Scraping Specs at a Glance

Where Contabo Wins for Scraping

• 32TB bandwidth is practically unlimited for any scraping campaign
• 8GB RAM supports 15-18 concurrent Puppeteer/Playwright instances
• AUP does not mention or restrict web scraping activities
• Support confirmed scraping is permitted via ticket response
• $0.22/TB is the lowest bandwidth cost on this list by a wide margin

Where Contabo Falls Short

• CPU benchmark (3200) is the lowest here — JavaScript rendering is slower per page
• Only 1 US datacenter — no IP geographic diversity from Contabo alone
• Network speed (800 Mbps) is below Vultr and DigitalOcean
• Setup fee on some plans adds to initial cost

#2. Hetzner — When You Need Each Request to Be Fast and Nobody to Bother You ($4.59/mo)

Where Contabo gives raw volume, Hetzner gives speed per operation. CPU benchmark 4300 means pages that took 1.8 seconds to render on Contabo completed in 1.2 seconds on Hetzner. Over a 100,000-page crawl, that 0.6-second difference saves 16 hours.

I tested a different architecture here: Scrapy handling the initial HTTP crawl, with Playwright as a fallback for pages returning incomplete HTML. This is far more efficient — 70-80% of pages on most sites render critical content in the initial HTML response. Only the remaining 20-30% need a full browser. On Hetzner's 2GB entry plan, this hybrid approach handled 200 concurrent Scrapy connections plus 3 Playwright instances simultaneously.

The 52K IOPS NVMe was an unexpected advantage. Scraping generates heavy writes — parsed data, raw HTML, logs, debug screenshots. On slower-disk providers, these writes bottleneck at hundreds of pages per minute. Hetzner's NVMe never became the limiting factor.

TOS-wise, Hetzner's abuse team gave me a two-sentence reply: "We do not monitor what you do on your server; we only intervene if we receive a valid abuse complaint." Over 14 days of testing, zero complaints, zero interventions.

Hetzner Two-Tier Scraping Architecture

# scrapy_settings.py — Hetzner CX22 (2GB RAM)
CONCURRENT_REQUESTS = 200      # HTTP-only, low memory
DOWNLOAD_DELAY = 1.5           # Polite crawl rate
CONCURRENT_REQUESTS_PER_DOMAIN = 8
AUTOTHROTTLE_ENABLED = True
AUTOTHROTTLE_TARGET_CONCURRENCY = 4.0

# Playwright fallback middleware
# Only triggered for pages returning <10KB HTML
# (indicates JS-rendered content not in initial response)
PLAYWRIGHT_MAX_CONTEXTS = 3    # 3 browsers × ~400MB = 1.2GB
# Remaining ~800MB for Scrapy + OS

Hetzner Scraping Specs at a Glance

Where Hetzner Wins for Scraping

• Fastest per-request performance on this list (4300 CPU, 960 Mbps network)
• 20TB bandwidth at $4.59/mo — best price per TB after Contabo
• 52K IOPS NVMe means disk writes never bottleneck your pipeline
• Abuse team is hands-off unless they receive a valid complaint
• Hourly billing lets you spin up temporary high-resource instances for big campaigns

Where Hetzner Falls Short

• Only 2GB RAM on the entry plan — limits pure Puppeteer approach to 3-4 instances
• Single US datacenter (Ashburn, VA) — no IP geographic diversity
• Account verification process can delay initial setup by 24-48 hours
• No additional IPv4 addresses available on cloud plans

#3. Vultr — The Anti-Ban Architecture: 9 Cities, 9 IPs, 9x Less Likely to Get Blocked

A single $5 Vultr instance is mediocre for scraping. Vultr is not a single-instance play — it is an architecture play.

I built this: 9 instances at $5 each ($45/month total), one per US datacenter — New Jersey, Chicago, Dallas, Seattle, Los Angeles, Atlanta, Miami, Silicon Valley, Honolulu. A central Redis queue distributes URLs. Each scraper pulls a URL, makes the request from its local IP, stores the result, pulls the next. The target site sees 9 unrelated IP addresses from 9 geographic locations making polite requests.

Results: the same total volume from a single Contabo IP produced 4 temporary bans over 7 days. The distributed Vultr setup: zero bans. The per-IP volume was low enough that no single address triggered any anti-bot threshold.

Vultr's AUP includes "network abuse" language that could theoretically cover aggressive scraping. In practice, I have run scrapers on Vultr for six months — but I keep rates conservative (max one request per second per instance) and address abuse complaints immediately. The one complaint I received came with a 24-hour resolution window: tight but workable.

Distributed Vultr Architecture

# deploy.sh — Spin up scrapers in all 9 US locations
REGIONS=("ewr" "ord" "dfw" "sea" "lax" "atl" "mia" "sjc" "hnl")

for region in "${REGIONS[@]}"; do
  vultr-cli instance create \
    --region "$region" \
    --plan "vc2-1c-1gb" \
    --os 2136 \              # Ubuntu 24.04
    --script-id "$STARTUP_SCRIPT" \
    --label "scraper-$region"
done

# Startup script installs Python, Scrapy,
# connects to Redis queue on the manager node,
# and starts pulling URLs automatically.
# Total setup time: ~4 minutes per instance.

Vultr Scraping Specs at a Glance

Where Vultr Wins for Scraping

• 9 US datacenter locations — unmatched IP geographic diversity
• Hourly billing lets you spin up 9 instances for a 3-day campaign and pay ~$5 total
• Snapshots clone a configured scraper to all 9 locations in minutes
• API-driven deployment enables fully automated scraper infrastructure
• Additional IPv4 addresses available at $3/month each for extra rotation

Where Vultr Falls Short

• 2TB bandwidth per $5 instance limits heavy individual-node scraping
• 1GB RAM on the $5 plan — HTTP-only scraping, no headless browsers
• AUP's "network abuse" clause creates some ambiguity for high-volume work
• $0.01/GB overage charges can surprise you if you do not monitor bandwidth
• Some datacenter IPs may already be flagged in anti-bot databases

#4. Kamatera — The RAM Slider That Lets You Build Exactly the Puppeteer Farm You Need

Every other provider sells fixed tiers. Want 16GB RAM on Contabo? You buy the $13.99 plan with 6 vCPUs and 400GB storage you do not need. Kamatera lets you configure 16GB RAM, 2 vCPUs, 30GB SSD for $22/month — a server shaped exactly like a Puppeteer workload: memory-heavy, CPU-light, storage-minimal.

Headless browser scraping has an extremely unbalanced resource profile. Each Chromium instance needs 280-520MB RAM but uses negligible CPU between page navigations. On the 16GB config, I ran 30 concurrent Playwright instances scraping real estate listings. Memory at 14.2GB, but the 2 vCPUs sat at just 40% average utilization. Six extra cores on a balanced plan would have been burning money doing nothing.

The 30-day free trial ($100 credit) is enough to run a real campaign and measure actual resource usage. I used it to discover my Playwright instances averaged 310MB each — lower than the 400MB I budgeted — letting me drop to 12GB and save $4/month.

TOS is moderate-risk. Kamatera's AUP prohibits "excessive abuse complaints" but does not mention scraping specifically. No issues in my test, but I ran lower volume than on Contabo. Treat it as tolerated, not guaranteed safe.

Kamatera Scraping Specs at a Glance

Where Kamatera Wins for Scraping

• Fully custom RAM/CPU/storage ratios match the headless browser resource profile
• Scale to 64GB RAM for massive concurrent browser farms (100+ instances)
• 30-day/$100 free trial covers a real scraping campaign for performance testing
• CPU score of 4250 delivers fast per-page JavaScript rendering
• API for automated provisioning and teardown of scraping infrastructure

Where Kamatera Falls Short

• Custom configs require manual cost calculation — no simple pricing page
• Fewer US datacenter locations than Vultr (2 vs 9)
• More expensive per GB of RAM than Contabo's fixed plans
• Control panel has a learning curve compared to Vultr or DigitalOcean
• AUP language on "excessive abuse complaints" creates some uncertainty

#5. DigitalOcean — The Orchestration Layer (Do Not Run the Scraper Here)

"If they suspended you, why are they on this list?" Because DigitalOcean solves a different problem. When your scraping operation outgrows cron jobs into a real data pipeline — job queues, monitoring, managed databases, Kubernetes — DigitalOcean's developer infrastructure is better than anything else here.

My production pattern: DigitalOcean runs the brain (Redis queue, PostgreSQL for results, monitoring, client-facing API). Contabo and Vultr run the actual scrapers. Scrapers pull URLs from DigitalOcean-hosted Redis, make requests from their own IPs, push results to DigitalOcean-hosted PostgreSQL. DigitalOcean never makes a single scraping request — it just coordinates.

DigitalOcean's 980 Mbps network and Python/Node.js client libraries make the orchestration layer responsive. The 1TB bandwidth limit is irrelevant when you are only handling API calls and database queries, not scraping traffic.

DigitalOcean Scraping Specs at a Glance

Where DigitalOcean Wins (As Orchestration)

• Best-in-class API and developer tools for managing scraping infrastructure
• Managed PostgreSQL and Redis for storing and queuing scraping jobs
• Monitoring and alerting for pipeline health — know when a scraper node goes down
• Terraform provider for infrastructure-as-code deployment
• 980 Mbps network makes the orchestration layer responsive

Where DigitalOcean Falls Short (As a Scraper)

• Suspended my scraping instance at hour 14 with no prior warning
• AUP explicitly mentions "automated access" and "data mining" as potential violations
• 1TB bandwidth on the $6 plan is laughable for actual scraping work
• $0.01/GB overage charges compound the bandwidth problem
• 1GB RAM on the entry plan limits headless browser instances to 2

Headless Browser RAM: The Numbers Nobody Publishes

Every "best VPS for scraping" article says "Puppeteer uses 200-500MB per instance." That range is so wide it is useless. I measured actual memory consumption across different types of target pages to give you numbers you can actually plan with:

Measured on Ubuntu 24.04, Puppeteer 23.x, Playwright 1.49, with --disable-dev-shm-usage and --disable-gpu flags. Memory measured via process.memoryUsage() and /proc/$PID/status VmRSS after page load complete and 2-second stabilization.

Key takeaways:

• Playwright Firefox uses 20-25% less memory than Puppeteer Chromium. Use Firefox unless you need Chrome DevTools Protocol features.
• --single-process flag cuts Puppeteer memory ~40% but crashes more. Fine for disposable jobs with retry logic.
• Block images/fonts: saves ~80MB per instance. Use page.setRequestInterception(true) to drop non-essential requests.
• Call page.close() between navigations. Chromium leaks ~50MB per 200 navigations on the same Page object.

Based on these numbers, here is how many concurrent Puppeteer instances each provider can handle on their entry scraping plan:

*Available RAM = Total RAM minus ~1.5GB for OS, scraping framework, and overhead. For medium-complexity pages (~380MB per Puppeteer instance, ~300MB per Playwright Firefox instance).

IP Rotation Strategies That Actually Work (Tested Three Approaches)

Three approaches I tested over 30 days, with real cost breakdowns:

Strategy 1: Multi-VPS Geographic Distribution (Best Value)

Deploy multiple cheap instances across locations. A central job queue distributes URLs so no single IP gets hammered.

• Setup: 5 Vultr instances × $5/month across 5 US cities = $25/month
• Result: Zero bans over 30 days at 500 requests/hour total (100 per IP)
• Best for: Sites without Cloudflare Bot Management
• Cost per 1M requests: ~$0.03

Strategy 2: Additional IPv4 Addresses on Single VPS

Buy extra IPs ($2-5/month each) and rotate between them at the socket level.

• Setup: 1 Vultr + 4 extra IPs = $17/month
• Result: Partial improvement. All 5 IPs share the same datacenter subnet — range-based blocking still catches this.
• Best for: Sites that rate-limit by individual IP, not datacenter range
• Cost per 1M requests: ~$0.02

Strategy 3: Residential Proxy Overlay (Nuclear Option)

Route traffic through residential proxy services. Your VPS handles compute; the proxy handles IP rotation through real ISP addresses.

• Setup: Contabo ($6.99) + Bright Data (~$10/GB)
• Result: Zero bans even behind Cloudflare Bot Management and DataDome
• Best for: Amazon, LinkedIn, large retailers
• Cost per 1M requests: $5-50 depending on page size

Start with Strategy 1. If blocked, determine whether it is per-IP (try Strategy 2) or per-range (you need Strategy 3). Most projects never need residential proxies.

Rate Limiting & Ethical Scraping: The Line Between Scraping and Attacking

Blunt truth: the difference between web scraping and a denial-of-service attack is rate limiting. A scraper sending 100 requests per second to a small business site is not "collecting data" — it is degrading performance for real users. The nginx logs show 6,000 requests/minute from one IP. That looks identical to a DDoS to the sysadmin watching their dashboard.

Here are the rate limits I use:

Practices that have kept me ban-free for three years:

• Check robots.txt. Violating it weakens your legal position even under the hiQ v. LinkedIn precedent.
• Never scrape behind login walls. Public data is fair game. Authenticated data is a different legal territory.
• Scrape off-peak (2-6 AM target timezone). Less traffic means less chance of triggering monitoring.
• Cache aggressively. Use ETags and Last-Modified headers. Do not re-scrape unchanged pages.
• Set a meaningful User-Agent with your contact email: MyScraper/1.0 (contact: alex@example.com). Webmasters can reach you instead of filing abuse complaints.
• Exponential backoff on 429/503. Double your delay, then double again. Hammering a server that says "slow down" is how you get permanently banned.

Complete Scraping VPS Comparison

*Kamatera pricing shown for recommended custom scraping configuration (16GB RAM / 2 vCPU / 30GB SSD). Entry plan starts at $4/mo with 1GB RAM.

Frequently Asked Questions