Source Deploy: cómo una carpeta se convierte en una app en ejecución

Arquitectura: qué ocurre tras cdnctl deploy

De su lado no interviene ningún repositorio git ni registro de contenedores. El flujo es:

• cdnctl empaqueta la carpeta en un tar.gz (hasta 128 MB) y lo sube al panel bajo su cuenta.
• El panel emite una URL de descarga firmada válida 30 minutos — la única vía por la que el entorno de build puede obtener su código.
• Un sandbox aislado (Kaniko dentro de un pod protegido por gVisor) descarga el archivo, lo desempaqueta y construye el Dockerfile. Los builds suelen terminar en un minuto.
• La imagen se sube al espacio privado de registro de su cuenta (registry.cdn.com.tr/<cuenta>/<app>) — nunca a un registro compartido o público.
• La app se crea o actualiza, se expone en su subdominio con SSL y se despliega. cdnctl espera e imprime la URL en vivo.

cdnctl.yaml: los campos que importan

cdnctl init escribe este archivo; usted lo edita y cdnctl lo lee en cada deploy.

• name — el nombre de la app; también semilla del subdominio en el primer deploy.
• port — el puerto del contenedor donde escucha su servidor (todas las interfaces, no localhost).
• healthcheck — ruta HTTP que la plataforma sondea; el deploy espera a que pase.
• method — auto, source, git o compose; source es la vía por carpeta descrita aquí.
• El propio manifiesto queda excluido del escaneo de cdnctl check: sus valores nunca silencian una advertencia sobre su código.

# cdnctl.yaml mínimo
name: task-tracker
port: 3000
healthcheck: /health
method: source

Límites — la letra pequeña honesta

• Archivo fuente: máximo 128 MB. Los proyectos Node caben de sobra al excluir node_modules (init escribe el .dockerignore).
• Tiempo de build: alrededor de un minuto para apps Node/Python típicas; los builds nativos pesados tardan más.
• La plantilla de Dockerfile cubre Node, Python, PHP y sitios estáticos; cualquier otra cosa necesita un Dockerfile escrito a mano (deploy lo usa tal cual).
• El pago queda en el panel: si la cuenta no tiene paquete de plataforma, deploy se detiene con el enlace de compra y cdnctl init --wait continúa tras el pago.

Solución de problemas: fallos que hemos vivido

Cada línea es un fallo real de ejecuciones en vivo, con la solución que funcionó.

• El contenedor entra en crashloop con ERR_DLOPEN_FAILED justo tras el deploy — la imagen contiene node_modules copiado de su máquina (módulos nativos compilados para otra plataforma). Solución: añada node_modules a .dockerignore y deje que npm install corra dentro del build. cdnctl check lo marca antes de subir.
• Build failed en el primer deploy — lea el log de build que imprime cdnctl deploy; la causa más común tras node_modules es una dependencia presente en local pero ausente de package.json/requirements.
• La app aparece stopped tras un create — ejecute cdnctl deploy de nuevo (0.18.0+ dispara el rollout por sí mismo; versiones antiguas requerían un deploy explícito).
• El sitio no responde aunque el build fue bien — el servidor escucha en 127.0.0.1 o en un puerto distinto al de cdnctl.yaml. Escuche en 0.0.0.0 y en el puerto declarado; check detecta el enlace a localhost.
• El healthcheck nunca pasa — la ruta no devuelve 200 o la app tarda en arrancar; verifique la ruta primero en local.

Los comandos, de principio a fin

cdnctl init          # detectar proyecto, escribir cdnctl.yaml + Dockerfile
cdnctl check         # pre-vuelo local: los errores bloquean, las advertencias avisan
cdnctl deploy        # empaquetar → subir → build → URL en vivo
cdnctl container apps logs --app <app_uuid> --tail 100   # logs de ejecución
cdnctl deploy-token create --name "agent"   # token restringido para agentes IA