Si estás desarrollando con IA —ya seas vibecoder, programador o alguien con experiencia— probablemente te estés preguntando qué opciones existen hoy para desplegar aplicaciones usando agentes. La realidad es que casi cualquier agente de terminal puede hacerlo y es relativamente sencillo, pero muchos no saben que pueden desplegar automáticamente en VPS, en plataformas as a service o en los grandes proveedores de nube.
En este artículo voy a resumir las tres categorías principales y algunos detalles extra. Para los ejemplos uso Claude Code por ser uno de los agentes más comunes, pero la idea es transferible a cualquier herramienta: Open Code, Codex o la que prefieras. Lo importante es entender el concepto de qué se está desplegando.
Las tres formas de desplegar en la nube
1. VPS. Los servidores privados virtuales han estado ahí desde siempre, y hoy también se pueden automatizar con IA. Incluso hay formas interesantes de montar un entorno de desarrollo dentro de este tipo de máquinas. Es un punto intermedio: no es excesivamente complicado, pero sí requiere que conozcas algunos temas de despliegue y de configuración, porque dentro de un VPS tienes control completo.
2. Platform as a Service (PaaS). Aquí entran Vercel, Railway, Render, Netlify y también Cloudflare. En estas nubes no tienes control sobre la máquina (al menos no por lo general): conectas tu cuenta de GitHub y el código se despliega en automático. La plataforma se encarga del despliegue, tú pagas una suscripción y te olvidas de administrar los servidores que están por debajo. Son las preferidas porque simplemente pides el despliegue y ya está, y hoy con agentes de IA también se puede hacer.
3. Las grandes infraestructuras de nube. AWS, Azure y Google Cloud. Para ser claros, estas engloban a las dos anteriores: en cualquiera puedes adquirir VPS y también tienen servicios equivalentes a los PaaS. Las menciono porque hace unos años desplegar aquí era mucho más complicado, y hoy incluso una persona con conocimientos medios de nube puede lograrlo.
Desplegar en un VPS con un agente
Cuando quieres comunicarte con un VPS, por lo general usas el protocolo SSH, que conecta tu computador con la máquina en la nube. Y aquí está la clave: si tienes Claude Code o cualquier agente similar en tu computador, estas herramientas pueden ejecutar comandos del sistema, y ssh es un comando globalmente disponible en Windows, Linux y Mac. El agente puede leer la salida de SSH y entenderla sin problema, porque es un protocolo ampliamente conocido. Una vez dentro del servidor, puede instalar cualquier cosa.
Para la demo utilicé un VPS de Hostinger, pero puedes usar cualquier proveedor, o incluso una máquina local en tu casa: otro computador, un Raspberry Pi o cualquier dispositivo al que puedas conectarte por SSH.
El proceso es simple: desde el panel del proveedor generas o cambias la contraseña del servidor (y recuerda mantenerla segura, porque cualquiera que la vea puede entrar), copias la dirección SSH, la pegas en tu terminal, confirmas la conexión, ingresas la contraseña y ya estás dentro del servidor.
A partir de ahí tienes dos opciones: tener Claude Code en tu máquina y dejar que se conecte por SSH, o instalarlo directamente en el propio VPS descargando el CLI para Linux (en unos segundos está listo). Por lo general lo ideal es la primera: el agente corre en tu máquina y se conecta al VPS.
Con eso puedes pedirle algo como:
Crea una landing page básica con HTML, CSS y JavaScript y luego despliégala en este VPS.
Le pasas la dirección SSH e incluso la contraseña (que puedes cambiar después; sería más limpio usar una llave pública, pero ese es otro tema). El agente crea el sitio, usa comandos como sshpass para transferir los archivos y configura todo. Algo muy importante: es buena idea saber qué está instalando y qué está añadiendo. En mi caso instaló Nginx, el programa que sirve la aplicación. Si entras a la IP de tu hosting, el sitio ya está desplegado y activo.
Y se puede ir más allá: el mismo Nginx puede servir muchos sitios. Puedes pedirle "crea un CRUD de JavaScript básico con localStorage y sírvelo en otra ruta del dominio principal" y tendrás dos aplicaciones distintas en el mismo servidor. Para saber cómo pedir esto sí necesitas tener una idea de qué hace el programa: entender Nginx te hace entender qué puede hacer la IA, porque al final la IA usa ese programa.
Casos reales y advertencias
Con este enfoque puedes hacer de todo. Tengo clientes que usan WordPress, y a veces no hago los cambios en local porque implica descargar, descomprimir y demás. Con Claude Code puedes hacer una modificación pequeña directamente si sabes que no va a alterar el sitio. Es un poco riesgoso porque puede hacer cambios fuertes, pero con una buena lógica de backups y sin miedo a modificar "en caliente", puedes avanzar muy rápido y trabajar en paralelo. El problema que la mayoría tiene es no saber qué tipo de cosas está haciendo el agente: en un punto puede instalar cosas o hacer más de lo que quisieras.
También puedes instalar en tu VPS proyectos como Dokploy, Coolify o Dokku, y así tener tu propia especie de Vercel autoalojado. Y si usas Docker, el agente puede instalarlo y desplegar una aplicación de Node con MySQL o lo que uses.
Un enfoque adicional que muchos están usando: en lugar de correr Claude Code desde tu computador, lo dejan instalado en el servidor, escuchando en una sesión persistente con herramientas como tmux, y usando los comandos de control remoto del propio agente. Así puedes enviarle instrucciones desde el móvil o desde donde estés, e incluso pedirle que modifique una aplicación en producción mientras se ejecuta. Están tratando de cambiar la idea de desarrollar en un dispositivo cliente y enfocarlo todo en el servidor. Es interesante —yo también lo uso de cierta forma— pero no es automático y tiene sus desventajas.
Desplegar en un PaaS con un agente
Esta es incluso más simple. Vercel, Railway, Render, Netlify y Cloudflare tienen algo en común: un CLI, un programa de consola. Y como ya vimos, cualquier agente puede usar estos CLI para desplegar. Desarrollas el proyecto en local y luego el agente usa el CLI para desplegarlo por ti.
En lo personal, a mis clientes los subo a Railway, principalmente porque es bastante barato, funciona bien y su CLI puede hacer la mayor parte del trabajo. Vercel también tiene CLI, pero me ha costado conectarlo últimamente y no lo uso mucho. Cloudflare es básicamente la competencia de Vercel y es más barato, pero necesitas adaptadores y cambiar un poco el código para desplegar ahí. Railway, en cambio, es más genérico: es como desplegar en un VPS, así que si mañana te aburres y quieres migrar, el código casi no cambia. De hecho, me ha pasado varias veces.
Para el ejemplo pedí:
Crea una aplicación de seguimiento de gastos con Vite, Express y PostgreSQL con Prisma. Simple y sin autenticación.
(Sin autenticación para no gastar tokens de más: si le pides auth puede meterse con roles y demorar bastante.)
El agente genera el proyecto con client (frontend) y server (backend). Lo pruebas en local, funciona, y ahora toca desplegarlo. Instalas el CLI de Railway con el comando para tu sistema operativo, ejecutas railway login, autorizas desde el navegador y listo, ya estás autenticado.
Aunque el CLI es más que suficiente, Railway también ofrece un skill: una forma en la que el agente conoce de antemano los comandos del CLI sin tener que estar probándolos o leyéndolos. Se instala a nivel de proyecto con un instalador (skills.sh) y sirve para Claude Code, Cursor, Codex y más herramientas. No es obligatorio, pero por lo general es buena idea.
Con el skill instalado, simplemente le dices "usa Railway y despliega esto" y ya está. En mi caso, el proyecto era backend + frontend, y Claude decidió combinarlos en un solo servicio de producción: transpiló el frontend dentro del backend de Express y desplegó eso. Para un proyecto pequeño tiene sentido. El resultado: la web en producción con su base de datos PostgreSQL, y puedes verificar los registros directamente desde el panel de Railway. Todo sin haber tenido que entrar manualmente a la plataforma.
Un apunte: si hoy una plataforma de nube no tiene CLI, se está quedando atrás. Los agentes están haciendo el trabajo que antes hacían las personas, y una nube sin CLI se ve anticuada. Es algo que muchas plataformas están actualizando.
Las grandes nubes: AWS, Azure y Google Cloud
El proceso es casi el mismo, porque las tres tienen sus propios CLI: AWS CLI en Amazon (un poco más difícil de instalar), gcloud en Google Cloud y az en Azure. Una vez instalados, le pides el despliegue a tu agente y ya está.
La diferencia es la escala. Amazon, Google y Microsoft tienen la mayor cantidad de servicios de internet: en AWS puedes tener VPS con EC2, una especie de Vercel/Railway con Amplify, bases de datos relacionales con RDS, servicios para Redis, DynamoDB y básicamente todo lo conocido. Y hay muchas formas de hacer lo mismo: puedes desplegar en un VPS con toda la responsabilidad, en un contenedor Docker con ECS, o si el frontend es puramente estático, compilarlo y servirlo con CloudFront.
Eso significa que delegar a una IA aquí conlleva más responsabilidad, principalmente porque se refleja en la facturación —ya sea del cliente que paga o tuya como desarrollador. Ya no es tan simple como decirle "despliégalo", porque el agente puede elegir cualquiera de los cinco o siete servicios que hacen lo mismo. Si bien la IA puede tomar la responsabilidad operativa, tú como desarrollador tienes que saber qué servicios está utilizando. Cada una de estas nubes es un mundo.
¿Entonces DevOps ya no es un trabajo?
En mi opinión, sigue siendo un trabajo bastante importante. Ya no es necesario escribir a mano el código de los entornos de despliegue, pero sí necesitas conocer de qué se tratan y entenderlos. De hecho, de eso siempre se trató esa profesión. El tema ya no está en hacer manualmente el despliegue, sino en entender qué hace cada servicio: así puedes migrar, entender los costos o cambiar de proveedor cuando haga falta.
Bonus: el entorno local (on-premise)
Hay una categoría más relacionada con los VPS: el entorno local, lo que la mayoría llama on-premise. Aquí también es posible hacer lo mismo; solo necesitas una conexión SSH con esa máquina y conocer los requerimientos del hardware. Si necesitas una red privada, está Tailscale, un proyecto muy bueno para tener una VPN en un entorno controlado y una forma segura de conectarse con agentes (tema que merece su propio artículo).
En mi homelab uso un Raspberry Pi: un computador muy pequeño que me garantiza tener la máquina aquí. Si necesitas algo más pesado para ejecutar modelos locales, están saliendo dispositivos tipo NVIDIA DGX Spark o AMD Ryzen AI Max (Strix Halo). Son equipos caros —pueden costar alrededor de $4,000, mientras que un Raspberry ronda los cien y algo de dólares— y funcionan como una especie de servidor on-premise. Para la mayoría, las opciones de nube siguen siendo las más accesibles.
Conclusión
Desplegar con IA hoy se resume en tres caminos: VPS por SSH (control total, pero necesitas saber qué se instala), PaaS vía CLI (la opción más simple, con Railway como mi favorita) y las grandes nubes vía sus CLI (más poder, más responsabilidad sobre servicios y costos). Cualquier agente de terminal puede hacerlo; lo que marca la diferencia es cuánto entiendes tú de lo que está pasando por debajo.
Si tienes dudas o se te ocurre otra forma de desplegar, déjame un comentario y puedo crear contenido dedicado a esos temas. Y si quieres asesorías personalizadas, puedes reservarlas en fazt.dev.