−25%

op Windows bij jaarbetaling, tot 31/10. Naar de pakketten

EQVPS
Aan de slag

VPS voor web scraping: setup, sizing, en eerlijke grenzen

6 jul 2026 · 4 min lezen · EQVPS Team

Een scraper op je laptop is prima tot je hem midden in een run sluit, je thuis-IP gerate-limit wordt, of je dezelfde job elk uur wilt laten draaien of je wakker bent of niet. Hem naar een VPS verplaatsen fixt alle drie: het blijft 24/7 up, het verbrandt de reputatie van je thuis-IP niet, en cron of een systemd-timer draait het op schema zonder jou. Hier is hoe je dat opzet, hoeveel server je werkelijk nodig hebt, en de delen die de meeste gidsen stilletjes overslaan.

Waarom een VPS je machine verslaat hiervoor

  • 24/7 en gepland. Een scraper die elk uur draait heeft een host nodig die altijd aan is. Een laptop niet.
  • Je thuis-IP blijft schoon. Scrapen van thuis betekent dat je residentiële IP de rate-limits en blokkades neemt. Doe het van een server en je eigen verbinding blijft ongemoeid.
  • Stabiliteit. Geen slaap, geen wifi-drops midden in een crawl, een gestage datacenter-verbinding, en een plek om resultaten te accumuleren.

De stack, en wat elk deel nodig heeft

Twee zeer verschillende gewichtsklassen, en het verkeerde plan kiezen verspilt geld of verhongert de job:

  • httpx / requests (Python) — voor API's, JSON-endpoints, en statische HTML. Dit is licht: het proces zit in tientallen megabytes, netwerk-gebonden, niet CPU-gebonden. Een $3 Nano (2 vCPU / 1 GB) draait dit comfortabel, zelfs met concurrency via asyncio.
  • Playwright / headless Chromium — voor JavaScript-gerenderde sites waar je een echte browser nodig hebt. Dit is de zware. Headless Chromium is ruwweg 300–400 MB per browser-instance, plus 100–200 MB per open context/tab, plus je runtime. Budget:
    • $5 Micro (2 vCPU / 2 GB) — één of twee browser-contexten tegelijk.
    • $8 Small (4 vCPU / 4 GB) — meerdere parallelle contexten, of zwaardere pagina's.

De vuistregel: je code is bijna nooit de bottleneck — Chromium is het. Dimensioneer voor de browser, niet de scraper.

Scheduling: systemd-timer boven cron

cron werkt, maar een systemd-timer is de betere standaard op een server die je onderhoudt: logs via journalctl, catch-up als de box down was, en inspecteerbare per-run-status. Een minimale setup:

# /etc/systemd/system/scrape.service
[Unit]
Description=Run scraper
[Service]
Type=oneshot
User=scraper
WorkingDirectory=/home/scraper/job
ExecStart=/home/scraper/job/venv/bin/python scrape.py
# /etc/systemd/system/scrape.timer
[Unit]
Description=Hourly scrape
[Timer]
OnCalendar=hourly
Persistent=true
[Install]
WantedBy=timers.target
sudo systemctl enable --now scrape.timer
journalctl -u scrape.service -f   # watch runs

Persistent=true is het stuk dat cron niet kan: als de server uit was op run-tijd, vuurt de job één keer af bij boot in plaats van stilletjes over te slaan.

Waar resultaten heen gaan

Houd het simpel en match de volume: SQLite voor gestructureerde data die je zult bevragen (één bestand, nul setup), CSV voor snelle tabulaire dumps, of een S3-compatibele object store wanneer resultaten de box ontgroeien of je ze off-server wilt. Roteer je logs (logrotate of journald-limieten) zodat een praatgrage scraper niet langzaam de disk vult.

Het eerlijke deel: egress-IP en reputatie

Dit is het detail dat beslist of je scraper een week werkt of op dag één geblokkeerd wordt.

Op een NAT-plan is het uitgaande adres niet van jezelf. De reputatie ervan ook niet — verkeer van anderen vanaf hetzelfde adres naar hetzelfde doel kan het adres gerate-limit krijgen voordat jij één verzoek stuurt. Prima voor licht, occasioneel scrapen; een risico op schaal.

Een dedicated IP geeft je je eigen egress-reputatie — niemand anders zijn gedrag beïnvloedt het. Maar het snijdt beide kanten op: agressief scrapen verbrandt je eigen schone IP, en zodra een doel het blokkeert, is het geblokkeerd. Een dedicated IP is controle, geen immuniteit.

Op echte schaal heb je externe proxy-pools nodig. Geen enkel IP — NAT of dedicated — kan load spreiden over vele adressen, wat serieus scrapen tegen IP-rate-limited doelen vereist. Proxies zijn een generieke, derde-partij-laag die je erbovenop toevoegt; de VPS draait de scraper, de proxy-pool levert de adressen. Verwacht niet dat één server-IP het werk van een proxy-pool doet.

Ethiek en de AUP — niet optioneel

Scraping leeft in een juridische en ethische grijze zone, dus wees helder:

  • Respecteer rate-limits en robots.txt. Throttle je verzoeken. Een beleefde scraper ziet eruit als verkeer; een onbeleefde ziet eruit als een aanval.
  • DoS je doel niet. Een site hameren tot hij omvalt is geen scrapen, het is een denial-of-service — en het is een acceptable-use-overtreding hier die de service beëindigt.
  • Scrape alleen wat je mag. Legale, toegestane data-verzameling is de lijn. Steek hem over en het is op jou.

De kern van de zaak

Een VPS is het juiste thuis voor een scraper: altijd-aan, gepland, en van je thuis-IP af. Match het plan aan de stack — $3 Nano voor httpx, $5 Micro tot $8 Small voor Playwright — plan met een systemd-timer, en wees eerlijk over IP's: een NAT-egress-adres is niet van jou, de reputatie ook niet, een dedicated IP is de jouwe om op te bouwen of te verbranden, en echte schaal betekent proxy-pools. Zet de box eerst op slot met de nieuwe-VPS beveiligingschecklist, dimensioneer het goed met de VPS-sizing-gids, en als betalen-zonder-kaart-privacy telt, is de anonieme VPS-uitsplitsing de eerlijke versie. Scrape verantwoord — de AUP is echt.


Klaar om te scrapen? Een Micro-plan is een solide start; grote gelijktijdige crawls doen het beter op Small.

FAQ

Welke VPS-specs heb ik nodig voor web scraping?

Hangt af van de stack. Een gewone HTTP-scraper (httpx/requests die API's of statische HTML raakt) is licht — een $3 Nano met 1 GB is ruim voldoende. Op het moment dat je een echte browser nodig hebt voor JavaScript-zware sites, wil Playwright met headless Chromium 2–4 GB: een $5 Micro voor één of twee browser-contexten, een $8 Small als je er meerdere parallel draait. Chromium is de RAM-vreter, niet je code.

Kan ik scrapen vanaf het eigen IP van de server, of heb ik proxies nodig?

Voor low-volume, goed-gedragend scrapen van sites die het toestaan, is het IP van de server prima. Op schaal, of tegen sites die rate-limiten per IP, heb je een externe proxy-pool nodig — één IP (NAT of dedicated) kan de load niet spreiden, en hameren vanaf één adres krijgt het snel geblokkeerd. Een dedicated IP geeft je een schone reputatie die je beheert; proxies geven je er veel.

cron of systemd-timer voor geplande scrapes?

Een systemd-timer, in bijna elk geval. Anders dan cron geeft het je proper logging via journalctl, dependency-ordering, automatische catch-up als de box down was, en per-run-status die je kunt inspecteren. cron werkt nog steeds voor doodsimpele jobs, maar een timer is de betere standaard op een server die je daadwerkelijk onderhoudt.

Is web scraping toegestaan op de VPS?

Legaal, respectvol scrapen — ja. Agressief scrapen dat rate-limits of robots.txt negeert, of dat neerkomt op een doel hameren tot een denial-of-service, is een acceptable-use-overtreding en krijgt de service beëindigd. Scrape wat je mag, throttle jezelf, en verander een scraper niet in een aanval.

Reacties

Nog geen reacties. Wees de eerste.

Laat een reactie achter

Reacties worden gemodereerd voordat ze verschijnen.