¿Qué especificaciones de VPS necesito para web scraping?

Depende del stack. Un scraper HTTP plano (httpx/requests golpeando APIs o HTML estático) es ligero — un Nano de 3 $ con 1 GB es de sobra. En el momento en que necesitas un navegador de verdad para sitios pesados en JavaScript, Playwright con Chromium headless quiere 2–4 GB: un Micro de 5 $ para uno o dos contextos de navegador, un Small de 8 $ si ejecutas varios en paralelo. Chromium es el devorador de RAM, no tu código.

¿Puedo scrapear desde la propia IP del servidor, o necesito proxies?

Para scraping de bajo volumen y buen comportamiento de sitios que lo permiten, la IP del servidor está bien. A escala, o contra sitios que rate-limitan por IP, necesitarás un pool de proxies externo — una IP (compartida o dedicada) no puede repartir la carga, y martillear desde una sola dirección la bloquea rápido. Una IP dedicada te da una reputación limpia que controlas; los proxies te dan muchas.

¿cron o timer de systemd para scrapes programados?

Un timer de systemd, en casi todos los casos. A diferencia de cron te da logging adecuado vía journalctl, ordenación de dependencias, recuperación automática si la máquina estuvo caída, y estado por ejecución que puedes inspeccionar. cron aún funciona para trabajos todo-simples, pero un timer es el mejor valor por defecto en un servidor que de verdad mantienes.

¿Está permitido el web scraping en el VPS?

Scraping legal y respetuoso — sí. El scraping agresivo que ignora los límites de tasa o robots.txt, o que equivale a martillear un objetivo hasta una denegación de servicio, es una violación de las condiciones de uso y hace que el servicio se termine. Scrapea lo que te está permitido, drénate a ti mismo, y no conviertas un scraper en un ataque.

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 $ (1 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.