Que specs de VPS eu preciso para web scraping?

Depende da stack. Um scraper HTTP puro (httpx/requests batendo em APIs ou HTML estático) é leve — um Nano de US$3 com 1 GB é bastante. No momento em que você precisa de um navegador de verdade para sites pesados em JavaScript, o Playwright com Chromium headless quer 2–4 GB: um Micro de US$5 para um ou dois contextos de navegador, um Small de US$8 se você roda vários em paralelo. O Chromium é o devorador de RAM, não o seu código.

Posso fazer scraping do próprio IP do servidor, ou preciso de proxies?

Para scraping de baixo volume e bem-comportado de sites que o permitem, o IP do servidor está bem. Em escala, ou contra sites que limitam taxa por IP, você vai precisar de um pool de proxies externo — um IP (compartilhado ou dedicado) não consegue espalhar a carga, e martelar de um único endereço o faz ser bloqueado rápido. Um IP dedicado te dá uma reputação limpa que você controla; proxies te dão muitos.

cron ou timer do systemd para scrapes agendados?

Um timer do systemd, em quase todos os casos. Ao contrário do cron ele te dá logging adequado via journalctl, ordenação de dependências, catch-up automático se a máquina estava fora e status por rodada que você pode inspecionar. O cron ainda funciona para jobs super simples, mas um timer é o melhor padrão num servidor que você de fato mantém.

Web scraping é permitido no VPS?

Scraping legal e respeitoso — sim. Scraping agressivo que ignora limites de taxa ou o robots.txt, ou que equivale a martelar um alvo até uma negação de serviço, é uma violação de uso aceitável e encerra o serviço. Faça scraping do que você tem permissão, autolimite-se e não transforme um scraper num ataque.

VPS para web scraping: setup, dimensionamento e limites honestos

Um scraper no seu notebook está bem até você fechá-lo no meio de uma rodada, seu IP de casa levar limite de taxa, ou você querer que o mesmo job rode toda hora esteja você acordado ou não. Movê-lo para um VPS conserta os três: ele fica de pé 24/7, não queima a reputação do seu IP de casa e o cron ou um timer do systemd o roda no horário sem você. Eis como configurar isso, quanto servidor você de fato precisa e as partes que a maioria dos guias silenciosamente pula.

Por que um VPS bate sua máquina para isto

24/7 e agendado. Um scraper que roda de hora em hora precisa de um host que está sempre ligado. Um notebook não é.
Seu IP de casa fica limpo. Fazer scraping de casa significa que o seu IP residencial leva os limites de taxa e os bloqueios. Faça-o de um servidor e a sua própria conexão fica intocada.
Estabilidade. Sem suspensão, sem quedas de wifi no meio de um crawl, uma conexão de datacenter estável e um lugar para acumular resultados.

A stack, e o que cada parte precisa

Duas classes de peso muito diferentes, e escolher o plano errado desperdiça dinheiro ou faz o job passar fome:

httpx / requests (Python) — para APIs, endpoints JSON e HTML estático. Isto é leve: o processo fica em dezenas de megabytes, limitado por rede, não por CPU. Um Nano de US$3 (1 vCPU / 1 GB) roda isto confortavelmente, mesmo com concorrência via asyncio.
Playwright / Chromium headless — para sites renderizados em JavaScript onde você precisa de um navegador de verdade. Este é o pesado. O Chromium headless é cerca de 300–400 MB por instância de navegador, mais 100–200 MB por contexto/aba aberto, mais o seu runtime. Orce:
- Micro de US$5 (2 vCPU / 2 GB) — um ou dois contextos de navegador por vez.
- Small de US$8 (4 vCPU / 4 GB) — vários contextos paralelos, ou páginas mais pesadas.

A regra prática: o seu código quase nunca é o gargalo — o Chromium é. Dimensione para o navegador, não para o scraper.

Agendamento: timer do systemd em vez de cron

O cron funciona, mas um timer do systemd é o melhor padrão num servidor que você mantém: logs pelo journalctl, catch-up se a máquina estava fora e status por rodada inspecionável. Um setup mínimo:

# /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   # acompanhe as rodadas

Persistent=true é a parte que o cron não consegue: se o servidor estava desligado na hora da rodada, o job dispara uma vez no boot em vez de pular silenciosamente.

Para onde vão os resultados

Mantenha simples e combine com o volume: SQLite para dados estruturados que você vai consultar (um arquivo, zero setup), CSV para despejos tabulares rápidos, ou um armazenamento de objetos compatível com S3 quando os resultados ultrapassam a máquina ou você os quer fora do servidor. Rotacione seus logs (logrotate ou limites do journald) para que um scraper tagarela não encha o disco devagar.

A parte honesta: IP de saída e reputação

Este é o detalhe que decide se o seu scraper funciona por uma semana ou é bloqueado no primeiro dia.

Num plano NAT, o tráfego de saída compartilha um IP de saída com outros clientes. A reputação desse IP é compartilhada — um vizinho fazendo scraping do mesmo alvo pode fazer o endereço levar limite de taxa antes de você enviar uma única requisição. Bom para scraping leve e ocasional; um risco em volume.

Um IP dedicado te dá a sua própria reputação de saída — o comportamento de mais ninguém a afeta. Mas corta dos dois lados: scraping agressivo queima o seu próprio IP limpo, e uma vez que um alvo o bloqueia, ele está bloqueado. Um IP dedicado é controle, não imunidade.

Em escala real, você precisa de pools de proxies externos. Nenhum IP único — compartilhado ou dedicado — consegue espalhar a carga entre muitos endereços, que é o que o scraping sério contra alvos com limite de taxa por IP exige. Proxies são uma camada genérica de terceiros que você adiciona por cima; o VPS roda o scraper, o pool de proxies fornece os endereços. Não espere que um IP de servidor faça o trabalho de um pool de proxies.

Ética e a PUA — não opcional

O scraping vive numa zona cinza legal e ética, então tenha olhos claros:

Respeite os limites de taxa e o robots.txt. Autolimite suas requisições. Um scraper educado parece tráfego; um mal-educado parece um ataque.
Não faça DoS no seu alvo. Martelar um site até ele cair não é scraping, é uma negação de serviço — e é uma violação de uso aceitável aqui que encerra o serviço.
Faça scraping só do que você tem permissão. A coleta de dados legal e permitida é a linha. Cruze-a e é por sua conta.

A conclusão

Um VPS é a casa certa para um scraper: sempre ligado, agendado e fora do seu IP de casa. Combine o plano com a stack — Nano de US$3 para httpx, Micro de US$5 a Small de US$8 para Playwright — agende com um timer do systemd e seja honesto sobre IPs: saída compartilhada compartilha reputação, um IP dedicado é seu para construir ou queimar, e escala real significa pools de proxies. Tranque a máquina primeiro com o checklist de segurança de VPS novo, dimensione-a certo usando o guia de dimensionamento de VPS, e se pagar-sem-cartão por privacidade importa, o detalhamento de VPS anônimo é a versão honesta. Faça scraping de forma responsável — a PUA é real.

Pronto para fazer scraping? Um plano Micro é um começo sólido; grandes crawls concorrentes se saem melhor no Small.