VPS para bots de trading: lo que importa

Qué necesita un bot de trading de un VPS

Un VPS para bots de trading se evalúa según cuatro aspectos: si el proceso vuelve a ejecutarse después de detenerse, si el reloj es correcto, si es difícil robar las claves de las API (interfaces de programación de aplicaciones) y si recibe una notificación cuando se detiene. La velocidad bruta ocupa un lugar muy inferior en esa lista para un bot minorista, porque la parte lenta de la ruta de la orden depende del bróker y de la distancia hasta este, no del host que ejecuta Python.

Esta es una guía de ingeniería. Nada de lo indicado aquí constituye asesoramiento financiero y no se analiza ninguna estrategia.

La disponibilidad depende de la disciplina de reinicio, no de un número en una página de ventas

Todos los hosts del mundo anuncian una disponibilidad del 99.9 por ciento. Esa cifra describe el hipervisor, no tu bot. Un bot se detiene por una excepción no controlada, una conexión websocket que nunca se vuelve a conectar o el OOM (out of memory) killer, mientras el servidor permanece activo todo el tiempo. Por tanto, la pregunta útil es qué ocurre durante los diez segundos posteriores a la salida del proceso.

Ejecuta el bot como un servicio de systemd y deja que el sistema de inicio gestione el reinicio. Un archivo de unidad hace esto en seis líneas.

[Unit]
Description=Trading bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 es la línea que muchos omiten. De forma predeterminada, systemd abandona después de 5 reinicios en 10 segundos y deja la unidad en estado failed para siempre. Ese es exactamente el comportamiento que no quieres a las 03:00. Establecerlo en 0 desactiva el límite de frecuencia. Así, un bot que entra en un bucle de fallos sigue intentándolo en lugar de quedar inactivo. RestartSec=10 evita que ese bucle sature el exchange con reconexiones.

Comprueba el archivo antes de confiar en él y después inícialo:

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable es la parte que permite sobrevivir a un reinicio, y las actualizaciones del kernel implican reinicios. Para comprobar si el bot ha estado deteniéndose silenciosamente, solicita a systemd el contador de reinicios:

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

NRestarts=0 después de una semana indica que el bot funciona correctamente. NRestarts=812 significa que has estado operando con un proceso que se reconecta durante toda la noche. La anatomía completa del archivo de unidad, incluidos los temporizadores para trabajos programados como un informe diario, se explica en ejecutar un programa como servicio de systemd.

Configure el reloj en UTC y demuestre que está sincronizado

Las API de exchanges firman las solicitudes con una marca de tiempo y rechazan todo lo que queda fuera de una ventana, a menudo de 5 segundos o menos. Un reloj desfasado produce errores que parecen fallos de autenticación, por lo que se rotan las claves durante horas antes de comprobar la hora. En las API de estilo Binance, el mensaje es literal: Timestamp for this request was 1000ms ahead of the server's time.

Configure el servidor en UTC. Las zonas horarias locales introducen un cambio por horario de verano que puede producirse en mitad de una sesión de trading.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu incluye systemd-timesyncd, que es un cliente SNTP (simple network time protocol). Es suficiente para los registros y no es adecuado para nada que deba mantenerse dentro de unos pocos milisegundos, porque consulta a un servidor y no ajusta el reloj de forma continua. Use chrony en su lugar:

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

La línea que debe leer de chronyc tracking es System time, por ejemplo System time : 0.000031415 seconds fast of NTP time. Cualquier valor inferior a unos pocos milisegundos es correcto. Si muestra Leap status : Not synchronised, chrony todavía no ha contactado con un servidor, normalmente porque el tráfico UDP saliente en el puerto 123 está bloqueado. Espere un minuto y vuelva a comprobarlo antes de modificar las reglas del firewall.

Mantén las claves de API fuera de los lugares que copias

Una clave de un exchange filtrada es peor que una clave SSH filtrada, porque el permiso de retiro permite convertirla en dinero al instante. Dos prácticas cubren la mayor parte del riesgo.

Primero, nunca concedas permisos de retiro a la clave de un bot y, si el exchange lo permite, vincula la clave a la dirección IP de tu servidor. Este es el único control que hace que una clave robada resulte casi inútil.

Segundo, mantén el secreto fuera del directorio del código. Todo lo que se encuentra dentro de /opt/tradingbot termina tarde o temprano en un repositorio git o en un archivo de respaldo. Colócalo en un archivo propiedad de root que solo lea systemd:

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

El archivo contiene líneas simples de KEY=value, sin comillas y sin export. El modo 640 con el grupo bot permite que el usuario del servicio lo lea y evita que cualquier otra persona pueda hacerlo. Verifícalo con sudo -u bot cat /etc/tradingbot/api.env y después con cualquier otro usuario; en ese caso debe fallar con Permission denied.

El bot no debe ejecutarse como root ni como tu usuario de inicio de sesión. Crea una cuenta de sistema sin shell y sin directorio principal para iniciar sesión:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

La explicación de cada una de esas opciones y del alcance real de ProtectSystem=strict se encuentra en ejecutar servicios con un usuario sin privilegios. El resto de la configuración base del servidor, las claves SSH y un firewall, se incluye en los primeros diez minutos en un VPS nuevo.

Descubre que está caído antes que tu bróker

systemctl status indica que el proceso está en ejecución. No indica que el bot esté haciendo algo. Un proceso atascado en un bucle de reintentos contra un websocket inactivo supera todas las comprobaciones que systemd puede realizar.

Usa un heartbeat. Uptime Kuma admite monitores push: espera que el bot llame a una URL según un intervalo y genera una alerta cuando la llamada deja de llegar. Coloca la llamada al final del bucle principal, después de la parte que demuestra que el bot está activo, como una lectura correcta de los datos de mercado.

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

Configura el intervalo del monitor en aproximadamente el doble del tiempo del bucle para que las variaciones normales no generen alertas innecesarias. Ejecuta el monitor en un servidor distinto del bot, porque un monitor que se detiene junto con aquello que supervisa no informa de nada. La configuración se explica en supervisión de estado autoalojada con Uptime Kuma.

Añade también una alerta de disco. Un bot que escribe registros detallados llenará el sistema de archivos root en pocas semanas, y un disco lleno impide escribir en la base de datos, no realizar la llamada de red, por lo que los síntomas son extraños. journalctl --vacuum-time=14d y una línea SystemMaxUse= en /etc/systemd/journald.conf mantienen acotado el journal.

La parte honesta: la latencia depende principalmente de factores ajenos a tu host

Aquí es donde el mercado de los productos VPS para trading deja de ser técnico. Las páginas de marketing citan cifras inferiores a un milisegundo e insinúan que el host es lo que se interpone entre tú y la ejecución de la orden. Para casi cualquier bot minorista, no es así.

Tu orden viaja desde el bot hasta el endpoint del exchange o del broker a través de Internet pública. Esa ruta está determinada principalmente por la distancia física y por el peering entre tu proveedor y el del endpoint. Un servidor en Frankfurt que se comunica con un endpoint en Tokio tiene aproximadamente 250 milisegundos de ida y vuelta, independientemente de la velocidad de la CPU. Después, los propios sistemas del broker añaden su cola, sus comprobaciones de riesgo y sus límites de frecuencia, que para una cuenta minorista normalmente se miden en decenas o cientos de milisegundos.

Mídelo en lugar de hacer suposiciones. curl informa de los tiempos de conexión y del primer byte para un endpoint real:

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

Ejecuta ese comando desde un servidor candidato antes de contratarlo. Si connect es de 0.180 segundos, estás en el continente equivocado, y eso sí merece corregirse. Si connect es de 0.004 segundos y ttfb es de 0.140 segundos, el retraso restante corresponde al procesamiento del broker, y ningún cambio de host lo reducirá.

Entonces, ¿cuándo importa el host? Cuando estás en colocación o conectado mediante una conexión cruzada al mercado y compites por la posición en la cola. Ese es un negocio diferente, con un presupuesto diferente. También importa cuando tu propio código es el cuello de botella: un bot que recalcula indicadores sobre todo el historial en cada tick puede consumir 200 milisegundos de CPU por ciclo. Esa es una latencia real que puedes controlar sin coste. Perfila el ciclo antes de buscar un servidor más rápido.

Lo que sí importa al elegir el host es la ubicación geográfica, una red estable y suficiente memoria para que el OOM killer nunca tenga que intervenir. En julio de 2026, un bot de Python con una sola estrategia y unos cientos de símbolos en memoria funciona correctamente con 2 GB de RAM y 2 vCPU. Añade memoria si conservas el historial de ticks en una base de datos local.

Lista breve antes de pasar a producción

1. systemctl is-enabled tradingbot muestra enabled y el servicio sobrevive a sudo reboot.
2. chronyc tracking informa de una desviación de la hora del sistema inferior a unos pocos milisegundos.
3. La clave de API tiene permiso de trading, no tiene permiso de retirada y usa una lista de IP permitidas si el exchange ofrece esa opción.
4. Al finalizar el proceso con sudo systemctl kill -s SIGKILL tradingbot, vuelve a iniciarse en un plazo de RestartSec.
5. El monitor de heartbeat te envía una alerta en un intervalo cuando detienes el bot deliberadamente.
6. Los registros tienen límites y el sistema de archivos raíz dispone de espacio libre suficiente en df -h.

Ejecuta todo en el sandbox del exchange o en modo de simulación durante una semana antes de usar fondos reales. Todos los elementos anteriores fallan al menos una vez durante esa semana. Ese es el objetivo de la semana.

FAQ

¿Un bot de trading necesita un servidor de baja latencia o bare metal?

Solo si compite por la velocidad de ejecución con otros participantes automatizados en el mismo mercado. En ese caso, normalmente se necesita colocación, no un VPS de propósito general. En un bot minorista, el tiempo de ida y vuelta depende principalmente de la ubicación geográfica y del procesamiento del propio broker. Elija un servidor cercano al endpoint de la API y mida con curl y mtr antes de pagar por algo más rápido.

¿Cuánta RAM y CPU necesita un bot de trading?

La mayoría de los bots de una sola estrategia están limitados por la red y permanecen inactivos entre eventos. En julio de 2026, 2 vCPU y 2 GB de RAM son suficientes para un bot de Python que supervise unos cientos de instrumentos. La memoria se convierte en el factor limitante cuando mantiene el historial de ticks en el proceso o ejecuta una base de datos local. Por eso, supervise free -h y el journal para detectar mensajes de OOM kill en lugar de hacer suposiciones.

¿Por qué mi API del exchange rechaza solicitudes con un error de timestamp?

El reloj del servidor se ha desviado fuera de la ventana de firma del exchange, normalmente unos pocos segundos. Instale chrony, confirme que chronyc tracking muestra un desfase pequeño de System time y un estado de salto sincronizado, y configure la máquina para usar UTC. Así, un cambio al horario de verano nunca desplazará la hora. Rotar la API key no corrige un problema del reloj.

¿Cómo evito que mi bot se detenga durante la noche sin que yo lo sepa?

Ejecútelo con systemd usando Restart=always y StartLimitIntervalSec=0. De ese modo, un bucle de fallos seguirá reintentando en lugar de detenerse permanentemente. Después, añada un heartbeat que el bot envíe al final de cada ciclo completado correctamente. El reinicio gestiona el proceso. El heartbeat detecta el caso en que el proceso está activo, pero bloqueado.

¿Puedo ejecutar el bot y la monitorización en el mismo VPS?

Puede hacerlo, pero la monitorización le dará información incorrecta el día que sea importante. Una interrupción que detenga el bot también dejará fuera de servicio la monitorización. Mantenga las alertas en otra máquina, preferiblemente con otro proveedor o en otra región, y use el servidor del bot solo para el bot y sus logs.