VPS para web scraping: configuración, dimensionamiento y límites honestos

Un scraper en tu portátil está bien hasta que lo cierras a mitad de ejecución, tu IP doméstica es rate-limitada, o quieres que el mismo trabajo corra cada hora estés despierto o no. Moverlo a un VPS arregla las tres: sigue arriba 24/7, no quema la reputación de tu IP doméstica, y cron o un timer de systemd lo ejecuta según horario sin ti. Aquí está cómo configurar eso, cuánto servidor necesitas de verdad, y las partes que la mayoría de las guías se saltan en silencio.

Por qué un VPS gana a tu máquina para esto

• 24/7 y programado. Un scraper que corre cada hora necesita un host que esté siempre activo. Un portátil no.
• Tu IP doméstica se queda limpia. Scrapear desde casa significa que tu IP residencial se lleva los rate-limits y bloqueos. Hazlo desde un servidor y tu propia conexión queda intocada.
• Estabilidad. Sin suspensión, sin caídas de wifi a mitad de crawl, una conexión de centro de datos estable, y un lugar para acumular resultados.

El stack, y qué necesita cada parte

Dos clases de peso muy distintas, y elegir el plan equivocado desperdicia dinero o mata de hambre el trabajo:

• httpx / requests (Python) — para APIs, endpoints JSON y HTML estático. Esto es ligero: el proceso se sienta en decenas de megabytes, ligado a la red, no a la CPU. Un Nano de 3 $ (2 vCPU / 1 GB) ejecuta esto cómodamente, incluso con concurrencia vía asyncio.
• Playwright / Chromium headless — para sitios renderizados con JavaScript donde necesitas un navegador de verdad. Este es el pesado. Chromium headless es grosso modo 300–400 MB por instancia de navegador, más 100–200 MB por contexto/pestaña abierta, más tu runtime. Presupuesta:
  • Micro de 5 $ (2 vCPU / 2 GB) — uno o dos contextos de navegador a la vez.
  • Small de 8 $ (4 vCPU / 4 GB) — varios contextos paralelos, o páginas más pesadas.

La regla general: tu código casi nunca es el cuello de botella — Chromium lo es. Dimensiona para el navegador, no para el scraper.

Programación: timer de systemd sobre cron

cron funciona, pero un timer de systemd es el mejor valor por defecto en un servidor que mantienes: logs a través de journalctl, recuperación si la máquina estuvo caída, y estado por ejecución inspeccionable. Una configuración mínima:

# /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   # observa las ejecuciones

Persistent=true es lo que cron no puede hacer: si el servidor estuvo apagado a la hora de ejecución, el trabajo dispara una vez al arrancar en lugar de saltar en silencio.

A dónde van los resultados

Mantenlo simple y casa el volumen: SQLite para datos estructurados que consultarás (un archivo, cero configuración), CSV para volcados tabulares rápidos, o un object-store compatible con S3 cuando los resultados superan la máquina o los quieres fuera del servidor. Rota tus logs (logrotate o límites de journald) para que un scraper parlanchín no llene lentamente el disco.

La parte honesta: IP de salida y reputación

Este es el detalle que decide si tu scraper funciona una semana o es bloqueado el primer día.

En un plan NAT, el tráfico de salida comparte una IP de salida con otros clientes. La reputación de esa IP es compartida — un vecino scrapeando el mismo objetivo puede hacer que la dirección sea rate-limitada antes de que envíes una sola solicitud. Bien para scraping ligero y ocasional; una responsabilidad a volumen.

Una IP dedicada te da tu propia reputación de salida — el comportamiento de nadie más la afecta. Pero corta en ambos sentidos: el scraping agresivo quema tu propia IP limpia, y una vez que un objetivo la bloquea, está bloqueada. Una IP dedicada es control, no inmunidad.

A escala real, necesitas pools de proxies externos. Ninguna IP única — compartida o dedicada — puede repartir la carga entre muchas direcciones, que es lo que el scraping serio contra objetivos rate-limitados por IP requiere. Los proxies son una capa genérica de terceros que añades encima; el VPS ejecuta el scraper, el pool de proxies provee las direcciones. No esperes que una IP de servidor haga el trabajo de un pool de proxies.

Ética y la AUP — no opcional

El scraping vive en una zona gris legal y ética, así que sé claro:

• Respeta los límites de tasa y robots.txt. Drena tus solicitudes. Un scraper educado parece tráfico; uno maleducado parece un ataque.
• No hagas DoS a tu objetivo. Martillear un sitio hasta que cae no es scraping, es una denegación de servicio — y es aquí una violación de las condiciones de uso que hace que el servicio se termine.
• Scrapea solo lo que te está permitido. La recopilación de datos legal y permitida es la línea. Crúzala y es cosa tuya.

La conclusión

Un VPS es el hogar adecuado para un scraper: siempre activo, programado, y fuera de tu IP doméstica. Casa el plan con el stack — Nano de 3 $ para httpx, Micro de 5 $ a Small de 8 $ para Playwright — programa con un timer de systemd, y sé honesto sobre las IPs: la salida compartida comparte reputación, una IP dedicada es tuya de construir o quemar, y la escala real significa pools de proxies. Cierra la máquina primero con la checklist de seguridad para un VPS nuevo, dimensiónala bien usando la guía de dimensionamiento de VPS, y si te importa la privacidad de pagar-sin-tarjeta, la aclaración del VPS anónimo es la versión honesta. Scrapea con responsabilidad — la AUP es real.

¿Listo para scrapear? Un plan Micro es un comienzo sólido; los crawls concurrentes grandes se llevan mejor con Small.