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 (1 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 deelt uitgaand verkeer één egress-IP met andere klanten. De reputatie van dat IP is gedeeld — een buur die hetzelfde doel scrapet 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 — gedeeld 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: gedeelde egress deelt reputatie, 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.
Reacties
Nog geen reacties. Wees de eerste.