Tu IA construyó una app que funciona. Así se pone en producción.

El problema de la app del viernes por la noche

Un gerente de empresa que conocemos pasó un viernes por la noche con un asistente de IA y, para la medianoche, tenía una herramienta interna genuinamente útil: seguimiento de tareas con la forma exacta en que trabaja su equipo, porque él conoce el trabajo mejor que cualquier proveedor. Funcionaba de maravilla — en su portátil.

Las opciones del lunes eran todas malas. Pedirle un servidor a TI y esperar semanas a que un ticket avance a paso de tortuga. Empujar los datos de la empresa a una plataforma de hobby extranjera. O alquilar un VPS pelado y volverse responsable de TLS, backups, parches y firewalls de la noche a la mañana. El código era bueno. Lo que faltaba era un camino.

Por qué las rutas de deploy habituales no encajan

Cada ruta convencional asume algo que este creador no tiene. Los deploys basados en git asumen un repositorio y un flujo de ramas. Los deploys basados en imágenes asumen un registry de contenedores y la soltura con Docker para alimentarlo. Ambos asumen que quien publica es, al menos a tiempo parcial, un ingeniero de despliegues.

Lo que el creador asistido por IA realmente tiene es más simple: una carpeta con código que funciona. Así que exactamente ahí debería empezar el camino — en la carpeta. Consulta Deploy desde Git cuando sí tengas un repositorio; los dos caminos terminan en la misma plataforma.

La carpeta es suficiente

Instala una CLI pequeña, ejecuta un comando en el directorio del proyecto, y cdnctl deduce el resto: el lenguaje y el framework, el puerto, si existe un Dockerfile (puede generar uno), e incluso qué agentes de programación con IA están configurados en el proyecto — porque el agente que escribió la app suele ser el que seguirá publicándola.

$ cdnctl init
Proje    : gorev-takip (node/express, port 3000)
Agent    : claude-code (claude on PATH), cursor
Paket    : ✓ Large (max 5 app)
Karne    : 2 HATA, 2 uyarı — ayrıntı: cdnctl check
Yazıldı  : cdnctl.yaml, AGENTS.md

→ Önce `cdnctl check` hatalarını düzeltin (deploy sonrası site açılmaz).

Un boletín de notas antes de que tu código salga de la máquina

Las apps generadas por IA fallan en producción por un puñado de razones muy repetibles, y todas son visibles en el código fuente antes de desplegar. cdnctl check corre por completo en tu máquina — no se sube nada de código — y se niega a dejar publicar una app que sabe rota. Estos cuatro hallazgos de abajo no son hipotéticos: son los fallos exactos con los que estaba escrita nuestra propia app de prueba, atrapados en la primera ejecución.

$ cdnctl check
[ERROR] bind-localhost (server.js:61)
        The app binds to 127.0.0.1 — unreachable inside a container.
        → Bind to 0.0.0.0 (just drop the host argument).
[ERROR] secret-in-code (server.js:10)
        A hard-coded secret (API key/token/password).
        → Move it to --secret KEY=VALUE; read it via process.env.
[WARNING] sqlite-single-pod
        SQLite loses data on restart / multiple replicas.
        → Mount a persistent disk or switch to a managed database.
[WARNING] no-healthcheck
        No /health route — the platform can’t tell your app is alive.

Un comando hasta una URL viva

Tras las correcciones, el despliegue es un solo comando. Por debajo, tu código fuente se archiva, se sube por TLS, se construye en una imagen de contenedor dentro de un sandbox aislado, se empuja al espacio de registry privado de tu propia cuenta y arranca detrás de un subdominio HTTPS real — pero nada de eso necesita tu atención. La primera ejecución tarda alrededor de un minuto; cada versión posterior es el mismo único comando.

$ cdnctl deploy
→ archiving source (gorev-takip)
→ uploading (0.1 MB)
→ starting build (Kaniko, isolated sandbox)
   build: running
   build: success        (41 s)
→ creating the app
→ assigning a subdomain
→ first deploy
→ waiting for the app to come up

✓ LIVE: https://ca…….cdn.com.tr

Seguridad y durabilidad son valores por defecto, no tareas

Las partes que hacían aterradora la ruta del VPS aquí son trabajo de la plataforma. El TLS se emite y renueva por ti. Los builds corren en sandbox, y las imágenes viven en un espacio de registry que pertenece solo a tu cuenta. Un healthcheck permite a la plataforma reiniciar tu app en el momento en que deja de responder. Y cuando el boletín detecta una base de datos en fichero, te señala los discos persistentes y MySQL/PostgreSQL gestionados — para que un reinicio de pod nunca se coma tus datos.

Tu agente de IA puede ejecutar todo este flujo por sí mismo

cdnctl init escribe una sección de deploy en AGENTS.md (y en CLAUDE.md cuando existe), de modo que el agente que construyó la app conoce los comandos exactos en su siguiente turno. Los agentes obtienen salida legible por máquina con --json, un servidor MCP mediante cdnctl mcp y — esto es importante — su propio token solo-deploy: puede subir, construir y publicar, y NO puede tocar el DNS, la facturación ni el resto de tu cuenta. Tu contraseña del panel nunca sale de tus manos. Los detalles están en las páginas de ayuda de cdnctl. Para el modelo de seguridad completo — los límites del token, la configuración de MCP y los límites verificados con pruebas — consulta dale a tu agente acceso de deploy de forma segura.

¿Cuál es tu camino?

Tres caminos, una plataforma. Si mantienes el código en un repositorio y quieres push-to-deploy, toma Deploy desde Git. Si ya construyes imágenes y ejecutas un fichero compose, consulta hosting Docker. Si lo que tienes es una carpeta que funciona — la situación del viernes por la noche — este camino se construyó para ti: instala cdnctl, ejecuta init, ejecuta deploy y envíale la URL a tu equipo.