El entorno de desarrollo con IA que nadie te enseña: agentes en un VPS

Llevo meses probando un entorno distinto, sobre todo en trabajos de verdad: tener la IA en la nube y lanzar desde ahí todos mis proyectos. Es decir, no tener Claude Code instalado en la laptop, sino en un VPS, y que desde esa máquina se ejecuten los proyectos, se haga el testing, se envíen notificaciones y se levanten previews.

Es posible. Pero en este artículo quiero contarte qué tan práctico es realmente, por qué algunos lo necesitan y otros no, y qué conlleva prepararlo para trabajo serio. La idea de fondo: poder trabajar desde cualquier lugar, incluso sin una computadora personal potente.

🔥 Patrocinado por Hostinger

¿Estás buscando dónde subir tus aplicaciones web hechas en Python, Node.js, PHP, Ruby o cualquier framework basado en esos lenguajes? Con un VPS de Hostinger despliegas fácil y te enfocas en construir mientras ellos sirven tu proyecto.

El plan KVM 2 te da 2 núcleos de CPU, 8 GB de RAM, 100 GB de disco NVMe y hasta 8 TB de transferencia, sobre procesadores AMD EPYC y red de 1 Gb/s. El flujo es simple: adquieres el plan, entras al panel de control, eliges el sistema operativo que prefieras y listo. Desde ahí puedes crear usuarios y modificar privilegios, usar plantillas preconfiguradas para saltarte la instalación manual, montar tu CMS favorito como WordPress o subir cualquier proyecto propio, y configurar un firewall para proteger tu sitio. Incluye además backups semanales gratuitos, snapshots manuales y un asistente de IA integrado para resolver dudas del VPS en lenguaje natural.

Con el código FAZT obtienes hasta un 10% de descuento:

👉 hostinger.com/fazt

El punto de partida: cómo trabajamos hoy

Tienes una computadora personal y ahí instalas tus herramientas: Claude Code, Codex, OpenCode o lo que uses —al final del día son bastante equivalentes—. Esto no tiene nada de malo. Es lo que siempre se ha hecho.

Lo que cambió es que los agentes actuales pueden correr en un servidor, y eso abre una arquitectura distinta: tu máquina personal se comunica con una máquina externa que está encendida el 100% del tiempo, y es esa máquina la que trabaja.

Las ventajas reales

1. El servidor funciona 24/7

Puedes delegar tareas de desarrollo a cualquier hora. Si un cliente reporta un error menor a las once de la noche y no estás cerca de la laptop, abres una app en el móvil, le envías un mensaje a tu servidor, y el agente corrige.

Para eso necesita acceso a la cuenta de GitHub donde está el código. El agente clona el repo, instala dependencias, y si le falta algo —Docker, Node.js, Go, Python— lo instala él mismo. Ni siquiera tienes que dejar todo preinstalado: si el agente puede ejecutar comandos, puede prepararse el entorno solo.

2. Desarrollo en paralelo de verdad

Puedes abrir una instancia del agente para un proyecto y otra instancia para otro proyecto distinto. Con un servidor de recursos decentes —pongamos 8 GB de RAM y 4 vCPU— alcanza para varios procesos simultáneos.

3. Tu máquina principal queda ligera

Aquí solo corren programas de desarrollo. No están compitiendo con tu calendario, tus apps de tareas, un juego en segundo plano. Separas los recursos y separas los conceptos: lo personal en tu máquina, lo de desarrollo en el servidor.

La consecuencia práctica: no necesitas una computadora potente para hacer este trabajo. Y si igual la tienes, mejor: puedes usarla para proyectos nuevos donde sí quieres controlar cada detalle.

4. Entornos aislados

Cada proyecto puede correr dentro de un contenedor Docker, o simplemente con puertos dedicados. Honestamente, para proyectos de desarrollo esto importa menos de lo que parece, pero si quieres el aislamiento estricto, se puede.

5. Entorno reproducible

Si mañana quieres hacer upgrade del servidor o darlo de baja, no hay problema: si guardaste la configuración, levantas otro y replicas el mismo entorno. Y con Linux puedes hacer un backup del sistema operativo entero, que es como hacer backup de tu entorno de desarrollo completo.

6. Portabilidad

Esta es la razón fuerte en mi caso. Antes, mover tu entorno de desarrollo era complicado: una máquina con muchas terminales, varias pantallas, muchos recursos. Con el entorno en un servidor, puedes estar en cualquier parte del mundo y delegar. Esa independencia es lo que antes no existía de forma cómoda.

Linux o Windows

En la gran mayoría de casos hablamos de Linux, porque es la preferencia estándar en servidores. Eso significa terminal: comandos, cómo se organizan las carpetas, programas nuevos.

Si trabajas con Windows, también se puede hacer exactamente igual, y tendrías un entorno gráfico. Mi recomendación: no es necesario. Con Linux te ahorras recursos, es mucho más ligero, y el backup completo es más simple.

Cómo lo controlas desde el móvil

Aquí está la parte que a más gente le llama la atención.

Bots de mensajería. En mi caso uso varios bots de Telegram, todos apuntando a la misma instancia:

• Un bot de asistente personal: lee correos, crea artículos, asigna tareas en otros sistemas.
• Dos bots de desarrollo: saben dónde están los proyectos y que tienen que delegar la escritura de código a Claude o Codex. Son dos porque a veces uno está ocupado con un proyecto y necesito lanzar un cambio en otro.

Si haces más tipos de tareas, creas más bots. La idea es delegar desde cualquier entorno a tu máquina principal.

Clientes SSH. También puedes conectarte directamente. Termius organiza todas tus conexiones y te las sincroniza entre escritorio y móvil, con soporte para SSH, Mosh, SFTP y port forwarding. En Android también existe Termux y hay muchísimas más opciones; en iOS igual. Al final la idea es la misma: conectarte a tu servidor de forma remota y ejecutar comandos.

No soy el único buscando esto

Durante este último año he visto a varias personas con plataformas propias moviéndose hacia este tipo de entorno. El caso más visible es Theo (t3.gg) con T3 Code.

Corrección importante sobre lo que dije en el video. Describí T3 Code como una plataforma de agentes en la nube que compite con ejecutar en máquina local. Es justo al revés, y eso refuerza el argumento del video: T3 Code es un control plane open source, MIT, "bring your own subscription" que corre un servidor local, envuelve los CLIs de Codex, Claude Code, Cursor, Grok y OpenCode, y te deja controlarlos desde web, escritorio y móvil. El trabajo se queda en tu propia máquina, no en una nube propietaria.

Y el detalle que más se parece a lo que propongo: con npx t3 connect esa máquina se convierte en un host de agentes permanentemente accesible, y la recomendación de Theo es reutilizar una laptop o PC viejo con Linux, entre otras cosas porque el sistema de archivos es más rápido (crear un worktree toma ~2 segundos frente a 30 segundos o 2 minutos en macOS).

Es decir: la idea se repite. Hay gente pagando su propio VPS, configurando este entorno, y conectándose por bots o por SSH desde el móvil.

Seguridad: la parte que no puedes saltarte

Al tener la máquina expuesta, estás más propenso a ataques de bots o a que alguien encuentre una vulnerabilidad. Y si entran a tu entorno de desarrollo, entran también al código de tus clientes.

Lo mínimo:

• No usar el usuario root. Crea un usuario con los permisos justos.
• Firewall activo, limitando qué se puede conectar y desde dónde.
• Una VPN, en lugar de solo exponer SSH con contraseña e IP.

Para la VPN te recomiendo mirar Tailscale. Lo instalas en el servidor, en tu laptop y en el móvil, y quedas con una red privada entre tus propios dispositivos: puedes conectarte desde fuera, pero solo desde los dispositivos que autorizaste.

Esto no es trabajo tirado a la basura aunque abandones el experimento: cuando desarrollas para un cliente igual vas a tener que desplegar en un servidor, y todo esto aplica.

El software que hace el trabajo

Gateways de mensajería: Hermes

Hermes Agent, de Nous Research, es un agente self-hosted que corre en tu servidor y se comunica contigo a través de un gateway de mensajería: Telegram, Discord, Slack, WhatsApp, Signal, email, Teams y bastantes más, todo desde un solo proceso.

Esta es la forma más sencilla de empezar. Lo instalas en el servidor, conectas tu proveedor, y ya tienes un asistente que puede instalar cosas y ejecutar cosas dentro de la máquina, todo a punta de mensajes.

Un matiz sobre las suscripciones. En el video dije que Hermes no puede conectarse a tu suscripción de Claude, solo delegar a Claude Code si está instalado. La documentación es un poco más precisa: sí ofrece OAuth con Anthropic, pero requiere plan Max más créditos de uso adicionales; con OpenAI el camino es device-code auth usando tu suscripción de ChatGPT o Codex. Lo que sí es cierto es que delegar al CLI que ya tienes instalado en el servidor sigue siendo la vía más directa para aprovechar tu suscripción.

Orquestación: Herdr

Si pagas varias suscripciones —Claude Code, Codex, OpenCode, Kimi— te vas a topar con esto: cada una es un programa independiente y no se comunican entre sí.

Ahí entra Herdr. Funciona como una terminal que puede ejecutar otros agentes de terminal, pero lo interesante no es dividir la pantalla —eso ya lo hace tmux— sino que los agentes se comuniquen entre ellos: lanzas Claude Code y le pides que abra Codex, y Claude puede lanzar esa instancia, reanudarla o mostrarte la otra terminal. Eso es orquestación de agentes.

Lo puedes instalar en el servidor, y tiene plugin de Telegram, así que también lo manejas por mensajería.

Los agentes

Claude Code, Codex, OpenCode, Kimi CLI y varios otros agentes de terminal populares. A partir de aquí instalas lo que quieras encima: skills, MCPs, programas adicionales. La IA los ejecuta por ti.

¿Cuánto cuesta esto?

Para un servidor donde vas a desarrollar —no desplegar las aplicaciones de tus clientes— mi recomendación es Hetzner, y en particular su sección de Server Auction.

Dos precisiones importantes. Primero: el Server Auction no vende VPS, vende servidores dedicados (bare metal) previamente desplegados y dados de baja, a precios reducidos. Rondan los €30 a €80 al mes y el hardware suele ser una o dos generaciones más antiguo, pero perfectamente decente para desarrollo.

Segundo, y esto refuerza la recomendación: Hetzner subió precios tres veces en 2026. El 1 de abril fue un alza general del 30-37% que tocó a clientes nuevos y existentes, y el 15 de junio vino la grande, donde las líneas de vCPU dedicada del cloud (CPX y CCX) subieron entre 113% y 209%. El Server Auction quedó prácticamente exento de esa ronda de junio, lo que lo convierte hoy en una de las formas más baratas de tener hardware propio ahí.

La lógica del auction es simple: Hetzner tiene muchos clientes, algunos cancelan, y esas máquinas no se dan de baja inmediatamente. Pones un presupuesto máximo y buscas la mejor relación de recursos.

Haciendo cuentas: si ya pagas $100 de Claude Code y $100 de Codex, en lugar de subir a $200 en uno de los dos, ese dinero puede irse a una máquina donde ambos corren todo el día.

Para quién NO es esto

Seamos honestos: esto no es para todo el mundo.

Si trabajas en un solo proyecto, con un solo cliente, montar todo esto es exagerado. No va en la línea de "todos deberían usarlo".

Vale la pena si:

• Tienes varios clientes y haces cambios continuamente
• O son pocos clientes pero muchos proyectos, con despliegues diarios
• Se te está volviendo incómodo manejar muchas instancias de terminal y múltiples chats
• Ya probaste Claude Code Desktop, Orca o Herdr desde tu máquina y te queda corto

Ahí probablemente sea momento de delegarlo a la nube.

Las desventajas que sí existen

Proyectos complejos piden un editor. Cuando el proyecto es grande y necesitas revisar archivos, quieres un editor de código. El código no tiene por qué estar en tu máquina —con VS Code te conectas por SSH al servidor y lo ves desde ahí— pero sí vas a querer una laptop para leer, aunque la ejecución siga centralizada en el servidor.

Conflictos de puertos. Cada app corre en un puerto. Levantas un proyecto en el 3000, levantas otro del mismo stack y cae en el 3001, y algunas variables se rompen porque esperan otro número. Hay que pensar en el manejo de puertos.

Una solución concreta es portless, de Vercel Labs, que reemplaza los números de puerto por URLs .localhost estables y con nombre:

npm install -g portless
portless myapp next dev
# -> https://myapp.localhost

Está pensado explícitamente para humanos y para agentes: si le dices a un agente "prueba el flujo de login en el dashboard", necesita una URL que no cambie entre arranques. Portless le asigna un puerto libre al azar y enruta por nombre.

El testing consume recursos. Puedes hacer end-to-end con Playwright o el framework que uses, pero esos programas levantan instancias de navegador, y los navegadores consumen bastante RAM. Dependiendo de lo que tengas, puede ralentizar la ejecución de todos tus agentes. Conviene saber qué hace cada proyecto antes de lanzarlo todo a la vez.

Esto no es vibe coding

Ojo con la lectura fácil. No se trata de "delego todo a la nube y mágicamente aparece la aplicación". Se trata de tener un entorno más producido, aislado, preparado para comunicación remota y sobre todo agnóstico: si mañana sale un agente o un modelo nuevo y quieres probarlo con tus proyectos, lo instalas en el servidor y sigues delegando desde donde estés.

La planificación sigue siendo tuya

Algo que muchos subestiman. Como vas a usar múltiples subagentes, esos subagentes necesitan saber qué hacer en qué punto. La planificación te da el panorama general y te deja ver cuánto avanzó realmente el proyecto.

Para eso sirve un software de planificación: Linear, Notion, Jira si vienes de empresa. Puede sonar a bloc de notas, pero con un proyecto grande tarde o temprano pierdes el hilo: qué está pendiente, qué está en progreso, qué completaste, qué revisó el cliente, qué falla reportó. No puedes mantener eso en la cabeza trabajando en varios proyectos.

Y no tienes que crearla a mano: con un MCP, tu agente se conecta a tu cuenta de Linear o Notion y la crea por ti.

De esto va el término software factory que se escucha últimamente: en lugar de ir lanzando conversaciones una a una con un agente, armas un sistema donde la colaboración entre agentes está automatizada y el input es planificación.

Suena prometedor, y de lejos parece que ya estuviera resuelto. No lo está. Llevo meses probándolo y todavía no lo logro del todo. Mi objetivo es tenerlo razonablemente armado para fin de año.

¿Y con modelos locales?

Sí, se puede, y eso te ahorraría la suscripción. Hace unos meses tuve en las manos un DGX Spark, el equipo de NVIDIA enfocado en correr modelos locales.

Mi conclusión honesta: los modelos locales están mucho mejor que antes y sirven para cosas prácticas, pero no es lo mismo que un modelo en la nube. Si haces landing pages y aplicaciones web típicas, probablemente no tengas problema. Si estás con software más complejo —me he topado con gráficos de sistemas petroleros y planos CAD— esos modelos sufren para entenderlo, porque no fueron entrenados con esa información ni tienen los parámetros para sostenerla.

Actualización de precio. En el video dije que el DGX Spark cuesta alrededor de $4.000. Ese era el precio de lanzamiento: en febrero de 2026 subió a $4.699, un 18% más, por la escasez global de memoria. Trae el superchip GB10 Grace Blackwell, 128 GB de memoria unificada y 4 TB de NVMe, y NVIDIA dice que corre inferencia de modelos de hasta 200.000 millones de parámetros en 4 bits.

Si vas por ese camino, el equipo reemplaza al VPS: ahí instalas Hermes, OpenCode, Herdr y los modelos. Pero no te compres el discurso de marketing. Mira el tamaño de los parámetros, pruébalo en la práctica, y si no te responde para el tipo de aplicación que haces, quédate con las suscripciones.

Las alternativas ya hechas

Sé que me lo van a mencionar: hay productos que hacen esto sin que configures nada.

Cursor tiene agentes en la nube: clonan el repo, hacen el cambio y te mandan un pull request a GitHub. Misma idea, ya desplegada. Los inconvenientes: salen más caros y no tienes control de la máquina, solo recibes el resultado en tu GitHub.

Claude Code también corre en la web con agentes en la nube.

Corrección sobre el costo. En el video comenté que Claude Code en la web se cobra casi como si consumieras la API. Revisando la documentación oficial actual, dice lo contrario: las sesiones en la nube comparten los límites de uso con el resto de tu cuenta de Claude y Claude Code, y no hay cargo de cómputo separado por la VM. Correr varias tareas en paralelo consume proporcionalmente más de tus límites, pero no es facturación API aparte. Puede que cuando lo probé hace meses el esquema fuera otro; hoy no lo es. Lo que sí sigue siendo cierto es la limitación de plataforma: clonar repos y crear pull requests requiere GitHub.

Precisiones sobre el video

Cinco cosas que revisé después de grabar:

1. T3 Code no es una plataforma cloud, es un control plane open source que corre en tu propia máquina y lo controlas desde web, escritorio o móvil. Es básicamente la misma arquitectura que propongo.
2. El Server Auction de Hetzner son servidores dedicados, no VPS. Y quedó exento de la subida de precios de junio de 2026, cuando el cloud subió hasta 209%.
3. Claude Code en la web no se cobra como API. Comparte los límites de tu suscripción, sin cargo separado por la máquina virtual.
4. El DGX Spark hoy cuesta $4.699, no $4.000. Subió en febrero de 2026 por la escasez de memoria.
5. Hermes sí tiene OAuth con Anthropic, aunque exige plan Max más créditos adicionales.

Preguntas frecuentes

¿Cuántos recursos necesito en el servidor? Con 8 GB de RAM y 4 vCPU corres varios agentes en paralelo sin drama. El cuello de botella suele aparecer cuando lanzas testing end-to-end, porque los navegadores consumen mucha memoria.

¿Esto reemplaza mi laptop? No del todo. Para proyectos complejos vas a querer un editor para revisar archivos. Lo que cambia es que tu laptop deja de ejecutar y pasa a ser solo el cliente.

¿Es seguro tener el código de mis clientes ahí? Solo si lo configuras bien: usuario sin privilegios de root, firewall, y una VPN tipo Tailscale que limite qué dispositivos pueden conectarse. Sin eso, estás exponiendo el trabajo de tus clientes.

¿Puedo usar mis suscripciones o tengo que pagar API? Puedes usar las suscripciones. Instalas los CLIs en el servidor, te autenticas, y programas como Hermes o Herdr los ejecutan por ti. Ese es justamente el punto: evitar el costo variable de la API.

¿Vale la pena si trabajo en un solo proyecto? No. Es sobreingeniería para ese caso. Tiene sentido cuando llevas varios proyectos o clientes con cambios frecuentes.

¿Los modelos locales me sirven para esto? Para aplicaciones web comunes, probablemente sí. Para dominios técnicos avanzados, no. Y el hardware para correrlos decentemente cuesta casi $5.000.

Conclusión

Si lo notas, esto se parece bastante a una agencia de desarrollo. Antes tomabas un proyecto y necesitabas varias personas: uno en frontend, otro en backend, otro en administración de proyectos, más todo un software de planificación y una organización grande.

Hoy eso se puede lograr a punta de agentes. Y no significa que no se necesiten personas: yo igual tengo que planificar, igual tengo que revisar que todo funcione, y al final hay una persona que asume la responsabilidad de entregarle el software al cliente. Es el mismo proceso, solo que automatizado entre comillas, porque no lo está al 100%.

Yo trabajo entre dos y tres proyectos por día, y este entorno me viene bien porque apenas empieza el día —o incluso sin estar frente a una computadora— puedo lanzar una tarea y va avanzando. Te mentiría si dijera que es perfecto. Pero poder lanzar varias tareas a la vez ayuda, y si tienes el hábito de armar planificaciones grandes, ayuda mucho más.

En los siguientes videos voy a desglosar cada pieza por separado: Herdr, Hermes, Claude Code, Codex. Si tienes dudas sobre este entorno, déjalas en los comentarios.

Recursos

• Tailscale — VPN entre tus propios dispositivos
• Hermes Agent — agente self-hosted con gateway de mensajería
• Herdr — orquestación de agentes de terminal
• T3 Code — control plane open source para agentes
• portless — URLs con nombre en lugar de puertos
• Termius — cliente SSH multiplataforma

¿Tienes dudas sobre tu stack o quieres una asesoría personalizada? Encuéntrame en fazt.dev.