Ejecuta un agente de IA 24/7 en un VPS.
Fuera del portátil, sobre metal que no duerme.
Para ejecutar un agente de IA 24/7 en un VPS necesitas cuatro cosas, ninguna de ellas ingeniosa: una máquina que se mantenga arriba, un supervisor que la reinicie, secretos que nunca entren en la imagen, y un límite de gasto — más un host que no exija tu identidad.
- 01
La mayoría de los agentes son pegamento limitado por E/S alrededor de una API de modelo alojada. La inferencia no ocurre en tu máquina, así que la máquina es pequeña: 2 vCPU y 4 GB sostienen un agente de bucle único.
- 02
El uptime es un problema de supervisor, no de hardware. Una unidad systemd o una política de reinicio de Docker — activada, y probada contra un reinicio real — es todo lo que hace falta.
- 03
Las dos cosas que de verdad muerden: un secreto horneado en una capa de imagen, y un agente sin tope de gasto dando vueltas toda la noche contra una API medida por uso.
Por qué tu portátil no es un despliegue. Cuatro modos de fallo, todos aburridos.
Un agente que funciona en tu máquina es un agente que funciona, no uno desplegado. La diferencia son cuatro problemas nada glamurosos, ninguno relacionado con el prompt engineering.
Suspensión. Cierras la tapa y el proceso queda suspendido. La gestión de energía frena el trabajo en segundo plano mucho antes de que se cierre la tapa, lo que produce la peor versión de este fallo: un agente que se ejecuta, pero tarde y de forma impredecible.
Rotación de IP. Una conexión doméstica o de cafetería te asigna una dirección nueva en cada reconexión. Todo lo que esté limitado por IP, cualquier webhook que necesite un callback estable, cualquier allowlist que hayas registrado, se rompe de forma intermitente.
Reinicios. Las actualizaciones del sistema operativo reinician la máquina según su propio calendario. A menos que el agente esté registrado con un gestor de servicios, lo que vuelve es un escritorio, no un bucle en ejecución. La mayoría se da cuenta una semana después.
Traslados. Viajas, cambias de máquina, reinstalas. Todo lo que solo viva en tu historial de shell no es reproducible — un agente configurado una tarde de marzo no tiene ningún procedimiento de despliegue.
Un servidor arregla estas cuatro cosas y nada más — ni la corrección, ni el coste, ni la seguridad. Te da un runtime cuyos fallos te corresponde arreglar a ti. Desconfía de quien te lo venda como algo más.
Dimensionar la máquina. Qué nivel de VPS para qué forma de agente.
El instinto es sobredimensionar, porque «inteligencia artificial» suena a algo pesado. No lo es, siempre que el modelo se ejecute en el hardware de otro: un agente que llama a una API alojada pasa su tiempo esperando E/S de red. Una tercera forma — ejecutar el modelo tú mismo — queda fuera del alcance de esta guía; esa carga de trabajo quiere una GPU más que una máquina virtual.
Forma uno — el bucle único. Un proceso, un bucle de sondeo o programado, una API de modelo alojada, estado en SQLite. Así son la mayoría de los agentes independientes y los bots de monitorización, y es realmente ligero.
Forma dos — el stack pequeño. El agente más Postgres, una cola respaldada por Redis, un worker y un almacén vectorial. Ahora la memoria es la restricción determinante — un modelo de embeddings cargado en el propio proceso quiere uno o dos gigabytes solo para él.
Frente al catálogo: Sentinel (NB-V1 — 2 vCPU, 4 GB RAM, 120 GB NVMe, 1 Gbps, ancho de banda ilimitado, $3.90/month) cubre la forma uno con margen de sobra. Garrison (NB-V2 — 4 vCPU, 8 GB, 240 GB, $7.90/month) es el suelo honesto para la forma dos en cuanto entran en juego Postgres y una cola. Ravelin (NB-V3 — 8 vCPU, 16 GB, 480 GB, 2.5 Gbps, $16.90/month) es para varios agentes compartiendo una misma máquina. La inferencia local pertenece al hardware dedicado.
Los planes son mensuales, con descuento por compromisos más largos — 10% a tres meses, 20% a seis, 30% a doce. Si tu agente es un cliente de trading solo para Windows en lugar de un proceso Python, los niveles de escritorio remoto existen para ese caso.
La ruta de despliegue — ejecuta un agente de IA en un VPS en unos quince minutos.
Aprovisiona la máquina con Ubuntu 24.04 LTS o Debian 13 — ambos disponibles en el momento del pedido, junto con Ubuntu 22.04, Debian 12, AlmaLinux 9 y Rocky Linux 9. Obtienes credenciales de root; lo primero que hay que hacer con ellas es dejar de usarlas. Si la autenticación por clave SSH es territorio desconocido, lee antes la guía de refuerzo de seguridad enlazada más abajo.
1 — Crea un usuario de servicio. adduser --system --group --home /srv/agent agent. El agente no debería ejecutarse como root ni tener una shell interactiva propia. Un comando ahora, y el radio de impacto se queda pequeño más adelante si alguna herramienta que invoca se usa en su contra.
2 — Lleva el código a la máquina. git clone en /srv/agent, o rsync si prefieres no dejar una deploy key en el servidor. Fija las dependencias: un lockfile es la diferencia entre un redespliegue que se reproduce y uno que te da sorpresas.
3 — Construye el entorno. python3 -m venv /srv/agent/.venv, y luego instala desde el lockfile con el pip de ese virtualenv. O instala uv y deja que gestione tanto el intérprete como el lockfile. Cualquiera de las dos opciones vale; mezclarlas no.
4 — Ejecútalo una vez a mano. sudo -u agent /srv/agent/.venv/bin/python -m agent --once. No te saltes este paso para ir directo a una unidad de servicio. Nueve de cada diez fallos aquí son una variable de entorno que falta o una ruta relativa a tu portátil, y ambos se leen con más claridad en una terminal que en journald.
5 — Entrégaselo a un supervisor. El siguiente capítulo. Esto es lo que convierte un script que tú iniciaste en un servicio que pertenece a la máquina. Si la secuencia te ha llevado bastante más de quince minutos, la causa casi siempre es una dependencia implícita de tu máquina de desarrollo — un binario global, una credencial en tu perfil de shell, una ruta fuera del repositorio.
Mantenerlo vivo 24/7. systemd, Docker y la trampa del bucle de fallos.
Un proceso que iniciaste en una sesión SSH muere cuando la sesión termina, y no vuelve tras un reinicio. La supervisión no es opcional, y tienes dos opciones razonables.
systemd, para un solo proceso. Una unidad en /etc/systemd/system/agent.service con User=agent, WorkingDirectory=/srv/agent, ExecStart apuntando al intérprete del virtualenv, Restart=always y RestartSec=5. Luego systemctl daemon-reload, y luego systemctl enable --now agent. El enable es lo que sobrevive a un reinicio; arrancarlo sin habilitarlo es la forma más común de perder un agente tres semanas después.
Docker, para un conjunto de cosas. Cuando el agente tiene hermanos — una base de datos, una cola, un navegador headless — descríbelos en un solo archivo Compose con restart: unless-stopped en cada servicio. unless-stopped se diferencia de always en un aspecto que importa: un contenedor que has detenido deliberadamente sigue detenido tras un reinicio del daemon.
La trampa del bucle de fallos. systemd limita la tasa de reinicios por defecto. Falla con suficiente frecuencia dentro del intervalo y la unidad entra en el estado failed y deja de intentarlo — un agente que parece haber muerto en silencio mientras el archivo de la unidad dice claramente Restart=always. Configura StartLimitIntervalSec=0 para reintentar indefinidamente, y sube RestartSec para que un agente roto no haga girar un núcleo toda la noche.
Estar vivo no es lo mismo que estar sano. Un bucle atascado en una lectura de socket durante nueve horas es, para todo lo que systemd puede ver, un proceso en ejecución. Expón un heartbeat: un watchdog con WatchdogSec, un HEALTHCHECK de Docker, o un archivo de timestamp que el agente actualiza en cada ciclo, con un timer que avise cuando se quede obsoleto.
Secretos. El archivo de entorno que nunca debe llegar a la imagen.
Un agente guarda material más peligroso que una aplicación web. Una clave de API de modelo es un instrumento de gasto; una clave de trading es una con apalancamiento; una clave de wallet son los propios fondos. Y a diferencia de una aplicación web, un agente actúa sobre texto que él no escribió, lo que hace que la frontera entre que la clave la tenga el agente o un atacante sea delgada.
Mantenlas fuera de la imagen. Los valores ENV y ARG en un Dockerfile se escriben en las capas de la imagen y son legibles con docker history por cualquiera que obtenga la imagen. Usa env_file: en Compose, o EnvironmentFile= en la unidad systemd, y mantén el archivo fuera del contexto de build.
Mantenlas fuera del repositorio. .gitignore y .dockerignore en el primer commit, no en el quincuagésimo. Una clave que alguna vez se ha commiteado queda comprometida incluso después de reescribir el commit, porque el objeto sobrevive en clones y forks. Rótala en lugar de reescribir el historial.
Restringe a qué puede llegar el archivo. Haz que el archivo de entorno pertenezca al usuario de servicio y ponle modo 600. Combinado con un usuario de servicio que no sea root, una dependencia comprometida en otra parte de la máquina no puede simplemente leer tus claves del disco.
Limita el alcance de cada clave en el emisor. Una clave por agente, con los permisos más estrechos que ofrezca el proveedor — solo lectura donde baste con leer, retiros desactivados en las claves de exchange, con allowlist de IP restringida al servidor. Una IP estable es una ventaja discreta de salir del portátil: por fin es posible usar allowlists. Si varias personas necesitan las mismas credenciales, ponlas detrás del gestor de contraseñas autoalojado de la guía complementaria.
Programación. Bucles, timers y la zona horaria que te muerde.
«Ejecutarse de forma continua» describe tres arquitecturas distintas, y elegir la equivocada es una fuente habitual de trabajo duplicado y ejecuciones perdidas.
El bucle residente. Un proceso de larga duración que duerme entre ciclos. Es el más fácil de razonar, y la opción por defecto correcta. Su debilidad es el estado: todo lo que está en memoria se pierde al reiniciar, así que cualquier cosa que deba sobrevivir a un fallo pertenece a SQLite o Postgres, no a una variable.
La ejecución programada. Un proceso que arranca, hace una unidad de trabajo y termina. Un timer de systemd con OnCalendar es la mejor herramienta aquí, sobre todo por Persistent=true: tras un periodo de caída, un timer persistente dispara la ejecución que se perdió, mientras que cron simplemente la salta.
La cola. Un productor encola tareas, y los workers las consumen. Esto es lo que quieres en cuanto las tareas llegan más rápido de lo que se completan. También te da reintentos, gestión de dead-letter y un tope de concurrencia.
Dos reglas elijas lo que elijas. Haz que cada tarea sea idempotente — un supervisor que reinicia tras un fallo va a reintentar tareas, y una tarea reintentada no debe publicar por duplicado ni pedir por duplicado. Y deja el reloj del servidor en UTC, convirtiendo solo en los bordes: un horario que se desplaza una hora dos veces al año es un bug tedioso de encontrar.
Darle herramientas al agente. Un servidor de herramientas en la misma máquina.
Un agente sin herramientas es un bucle de chat. Las herramientas son lo que le permite leer un repositorio, consultar una base de datos, hacer un pedido o abrir un issue — y en cuanto el agente vive en un servidor, ellas también deberían vivir ahí.
El Model Context Protocol se ha convertido en la forma habitual de exponer esas herramientas, y un servidor que ejecutas de forma privada es fácil de colocar junto al agente: misma máquina, misma interfaz privada, sin necesidad de exposición pública. Las guías complementarias lo cubren en detalle — alojar un servidor MCP remoto recorre TLS, el transporte streamable-HTTP, OAuth y la agent card, mientras que el ángulo del alojamiento sin identidad cubre el mismo stack desde el lado de la identidad.
Vincúlalo primero a localhost. Si el único consumidor es el agente en la misma máquina, el servidor de herramientas no tiene ninguna razón para ocupar un puerto público. Vincúlalo a la dirección de loopback y sáltate el certificado. Expónlo públicamente solo cuando una segunda máquina lo necesite — y entonces necesita TLS y autenticación, no solo una de las dos.
Dale a las herramientas la mínima autoridad que funcione. El agente decide qué herramienta invocar basándose en texto, y parte de ese texto viene de fuera. La inyección de prompts no es hipotética para un agente que lee páginas web o bandejas de entrada: es el caso esperado. A una herramienta que solo puede leer no se la puede convencer de escribir. Donde una herramienta deba escribir, haz que las rutas destructivas requieran confirmación humana.
Si estás construyendo herramientas para agentes de otras personas y no para el tuyo propio, la API de máquina y la superficie orientada a agentes documentan cómo esta plataforma expone el aprovisionamiento directamente a un agente.
Observabilidad y coste. Qué registrar, y el kill-switch para lo descontrolado.
Dos modos de fallo dominan los despliegues reales de agentes, y ninguno es un crash. Uno es el agente que se ejecuta perfectamente y no produce nada útil. El otro es el agente que se ejecuta perfectamente y produce una factura de API de cuatro cifras en una sola noche.
Registra la forma, no el contenido. Timestamp, id de tarea, número de pasos, nombres de las herramientas invocadas, totales de tokens, duración, resultado. Eso responde a cualquier pregunta operativa que de verdad vayas a hacerte. Los prompts y completions completos son una transcripción de todo lo que se le ha pedido hacer al agente, en texto plano, en un disco dentro del edificio de otra persona.
Ponle un tope a la retención. journald sigue creciendo hasta que le dices que no lo haga. SystemMaxUse y MaxRetentionSec en journald.conf ponen un límite tanto al tamaño como a la antigüedad. Un agente parlanchín llena un disco en semanas si no lo haces, y un disco lleno falla de formas mucho más difíciles de leer que un crash limpio.
Tres capas de control del gasto. En el proveedor, un tope duro sobre la clave de API — el único límite que ningún bug de tu código puede saltarse, y el que la gente se salta. En el agente, un contador de tokens por ejecución con un umbral de aborto. Alrededor del agente, un número máximo de pasos y un timeout de reloj real, para que un modelo discutiendo consigo mismo se detenga a las veinte iteraciones y no a las cuatro mil.
Construye el kill-switch antes de necesitarlo. Un solo comando que lo detiene todo: systemctl stop agent, o docker compose down. Asegúrate de que no requiera un portátil concreto con una clave concreta dentro. La diferencia entre una mala noche y un mal mes es si detener algo descontrolado te lleva diez segundos o una hora.
El suelo de identidad. Lo que sabe el host — y de qué no puede protegerte.
Un agente es un proceso de larga duración con credenciales, que actúa en tu nombre desde una dirección estable, de forma continua. Eso hace que el registro del alquiler sea más interesante que para un sitio web estático: está haciendo cosas atribuibles a ti, cada hora, durante meses.
El suelo aquí es una dirección de correo y una contraseña para registrarte, pago en ocho activos — Bitcoin, Ethereum, Tether en dos cadenas, Monero, Litecoin, TRON y Solana — y ningún documento de identidad en ninguna etapa. Los centros de datos están en cuatro regímenes constitucionales nórdicos: Stockholm, Helsinki, Oslo y Reykjavík. La doctrina operativa establece qué se retiene; la página de red cubre el enrutamiento.
Ahora el límite, que importa más que el discurso comercial. Un host que no pide identidad elimina el registro del alquiler. No toca la capa de inferencia: tu agente se autentica ante un proveedor de modelo con una clave ligada a una cuenta, desde una IP estable, en cada llamada. Si esa cuenta está a tu nombre legal — y para la mayoría de la gente lo está —, la identidad queda establecida ahí, sin importar quién alquile el hierro. La capa del host elimina un eslabón: uno real, y solo uno.
Lo que sigue no tiene nada de glamuroso. Compartimenta: un agente, un servidor, una clave, una wallet. Refuerza la seguridad de la máquina el día uno y no el día treinta — la checklist de la primera hora es una hora bien invertida en una máquina que va a funcionar sin supervisión durante meses. Si el agente necesita llegar a una red privada, termínala en el servidor con un túnel en lugar de exponer servicios — la guía del túnel cubre la configuración. Y paga en cripto desde una wallet que no sea la misma con la que opera tu agente.
Nada de esto es exótico, y nada de esto es una garantía. Es la disciplina ordinaria de ejecutar algo que actúa en tu nombre mientras duermes — que es todo lo que significa «operación continua». El resto del clúster está en el índice de guías.
Preguntas, respondidas.
Siete preguntas que se hacen los desarrolladores antes de sacar un agente de localhost — y durante el primer mes después.
¿Cuánto VPS hace falta para ejecutar un agente de IA 24/7?
Menos de lo que la gente espera, porque la inferencia ocurre en el hardware del proveedor, no en el tuyo. Un agente que llama a una API de modelo alojada y ejecuta un bucle de sondeo es un proceso limitado por E/S: el nivel Sentinel (2 vCPU, 4 GB RAM, 120 GB NVMe, $3.90/month) encaja con holgura. Sube a Garrison (4 vCPU, 8 GB, $7.90/month) en cuanto añadas Postgres, una cola y un modelo de embeddings local.
¿Es mejor usar systemd o Docker para mantener el agente en marcha?
Ambos funcionan; lo que cambia son los modos de fallo. Una unidad systemd con Restart=always es el camino más corto para un solo proceso y te da journald, límites de recursos y orden de arranque sin coste añadido. Docker con restart: unless-stopped es mejor cuando el agente tiene hermanos, porque Compose describe todo el conjunto en un solo archivo. Lo que importa más es que de verdad lo actives (enable) y que pruebes un reinicio antes de darlo por terminado.
¿Por qué mi agente deja de reiniciarse tras unos cuantos fallos?
Porque systemd limita la tasa de reinicios. StartLimitBurst y StartLimitIntervalSec permiten un número reducido de reinicios dentro de una ventana corta; supéralos y la unidad entra en el estado failed y se queda ahí, lo que parece exactamente una muerte silenciosa. O arreglas el fallo de fondo — la respuesta correcta — o configuras StartLimitIntervalSec=0 para desactivar el limitador y RestartSec=10 para que un agente en bucle de fallos no queme un núcleo reintentando.
¿Dónde hay que guardar las claves de API?
En un archivo que la imagen del contenedor nunca llega a ver. Mantén un archivo de entorno fuera del contexto de build, referenciado con EnvironmentFile= en la unidad systemd o env_file: en Compose, propiedad del usuario de servicio con modo 600. Nunca uses ENV ni ARG en un Dockerfile para un secreto: esos valores quedan horneados en las capas de la imagen y se pueden leer con docker history. Añade el archivo a .gitignore y .dockerignore antes del primer commit.
¿Cómo evitar que un agente se gaste todo el presupuesto de API en una sola noche?
Tres capas, y conviene tener las tres. En el proveedor: un límite de gasto duro sobre la clave de API, el único límite que ningún bug de tu código puede saltarse. En el agente: cuenta tokens o llamadas por ejecución y aborta por encima de un umbral. Alrededor del agente: un tope de pasos por tarea y un timeout de reloj real. Ningún host puede hacer esto por ti — un VPS es capacidad alquilada, no un guardián de presupuesto sobre la API de otro.
¿Qué no se debe escribir nunca en los logs del agente?
Prompts y completions completos, argumentos de herramientas en crudo, claves de API, material de wallet y cualquier cosa que haya escrito un usuario. Registra en su lugar la forma de la ejecución: timestamp, id de tarea, número de pasos, nombres de herramientas, totales de tokens, duración, resultado. Un log de agente demasiado detallado es una transcripción de todo lo que se le ha pedido hacer al agente, en texto plano, en un disco que no controlas físicamente.
¿Un host sin KYC hace anónimo a tu agente?
No, y merece la pena ser precisos. Un registro sin documento de identidad y un pago en cripto significan que el host no tiene identidad legal que vincular al servidor. Eso no cambia nada respecto al proveedor del modelo: tu agente se autentica ante esa API con una clave ligada a una cuenta, desde una IP de servidor estable, en cada llamada. La capa del host elimina un eslabón de la cadena — el registro del alquiler — y eso es todo lo que elimina.
Alquila un VPS sin KYC, paga en cripto, saca el agente de tu portátil esta noche.
Sentinel — 2 vCPU, 4 GB RAM, 120 GB NVMe, ancho de banda ilimitado, $3.90/month — sostiene un agente de bucle único con margen para su servidor de herramientas al lado. Una dirección de correo y una contraseña para registrarte; ningún documento en ninguna etapa.
Última revisión · 2026-08-24 · Fuentes · páginas de manual de systemd.service, systemd.timer y journald.conf, documentación de restart-policy de Docker y de Compose, especificación del Model Context Protocol, catálogo de NordBastion · Cadencia · anual
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Docker Compose, PostgreSQL, webhooks que funcionan — automatización que le pertenece.
Ollama en CPU, sin GPU: qué modelo cabe en 4, 8, 16 o 32 GB.