De una imagen a una URL publica, sin correr servidores
Poner un solo contenedor en internet normalmente significa aprovisionar un host, instalar un runtime de contenedores, conectar un reverse proxy, obtener un certificado, y abrir puertos de firewall — mucho trabajo indiferenciado por una sola API. Container Apps colapsa eso: le das una imagen y un puerto, y te devuelve una URL name.cdn.com.tr en vivo, asegurada con HTTPS. No hay host que parchear, ni nginx que configurar, ni cron de certbot que vigilar, porque el edge y el TLS son parte de la plataforma.
Healthchecks y rollouts sin tiempo fuera de linea
Un deploy que intercambia contenedores en el instante en que el proceso arranca dejara caer solicitudes mientras la app todavia esta calentando. La plataforma usa tu ruta de healthcheck para decidir la disponibilidad: en un deploy nuevo levanta el contenedor nuevo, espera a que el healthcheck pase, desplaza el trafico, y solo entonces retira el anterior. Eso significa que una imagen defectuosa que nunca se vuelve saludable no tumba el servicio — la version anterior sigue sirviendo hasta que la nueva se demuestra a si misma.
Entorno y secrets hechos correctamente
Las apps twelve-factor leen su configuracion del entorno, y los contenedores no son diferentes. La configuracion sencilla entra como variables de entorno; cualquier cosa sensible — contraseñas de base de datos, API keys de terceros, secrets de firma — entra como un secret que se almacena cifrado y se muestra solo por nombre de clave, nunca por valor, despues de guardarse. Cuando conectas object storage o una base de datos administrada, sus credenciales se inyectan de la misma forma, asi que nada sensible termina horneado en la imagen ni impreso en un log de build.
Escalado y planes de recursos que se ajustan a la carga real
Eliges un plan de recursos (CPU y memoria) por app y un numero de replicas, asi una herramienta interna de bajo trafico y una API publica no tienen que compartir la misma huella. Correr multiples replicas tambien te da resiliencia: si un contenedor se esta reiniciando, los demas siguen sirviendo. Como los rollouts estan controlados por salud, escalar hacia arriba o desplegar una nueva version no crea un momento en que la app quede inalcanzable.
Ruta edge, Auto SSL, y WAF delante de tu API
Cada container app expuesta se alcanza a traves del edge de cdn.com.tr, asi que las mismas protecciones que obtienen tus sitios web aplican a tus APIs. Auto SSL provee y renueva el certificado, el WAF filtra trafico malicioso y de escaneres antes de que llegue a tu servicio, y puedes cachear respuestas GET seguras en el edge para quitarle carga de lectura al contenedor. Tu contenedor origin nunca es direccionado directamente por el publico — solo recibe el trafico que el edge reenvia.
Panel o cdnctl, y compone con tu stack
Todo lo que puedes hacer en el panel — desplegar, definir env y secrets, escalar, leer logs, reiniciar — tambien esta disponible a traves de la herramienta de linea de comandos cdnctl, asi que las operaciones de contenedores encajan en scripts y CI. Container Apps tambien es el destino de Docker Compose Instant Deploy: un archivo compose multi-servicio se convierte en varias container apps mas add-ons administrados en un solo apply, que es la forma mas rapida de levantar un stack existente en lugar de recrear cada servicio a mano.
Como desplegar, paso a paso
Crea una container app
En el panel abre Container Apps y crea una app a partir de una imagen prearmada, por ejemplo myorg/api:1.4 de Docker Hub o un registry privado. Define el puerto de contenedor en el que escucha tu servicio para que la plataforma sepa a donde enviar el trafico.
Agrega una credencial de registry privado (si hace falta)
Si la imagen es privada, agrega un usuario y token de acceso del registry en Container Apps → registry credentials una sola vez, para que la plataforma pueda extraerla en cada deploy. Las imagenes publicas se saltan este paso por completo.
Define entorno, secrets, y healthcheck
Agrega la configuracion sencilla como variables de entorno y los valores sensibles — API keys, contraseñas de base de datos, tokens — como secrets, que se almacenan cifrados y nunca se vuelven a mostrar. Define una ruta de healthcheck para que la plataforma sepa cuando un contenedor nuevo esta realmente listo para servir, no solo iniciado.
Despliega y expon
Despliega la app, luego expon el puerto web para obtener una URL gratuita name.cdn.com.tr con HTTPS automatico, o conecta tu propio dominio. El trafico ahora fluye a traves del edge de cdn.com.tr hasta tu contenedor, con el SSL terminado en el edge.
Escala, observa logs, y despliega actualizaciones
Define replicas y un plan de recursos para la carga que esperas, transmite logs desde el panel para depurar, y sube un nuevo tag de imagen para disparar un rollout sin tiempo fuera de linea. Prefieres la terminal? cdnctl realiza las mismas operaciones de deploy, escalado, y logs desde tu shell.
Escenarios de ejemplo
Una API en Node o Go se despliega desde una imagen, se expone en un dominio con Auto SSL, y se protege con el WAF, con respuestas GET seguras cacheadas en el edge.
Un solo servicio corre con su propio plan de recursos y secrets, escalado a unas pocas replicas por resiliencia, sin compartir host con el resto del stack.
Un equipo de producto levanta un entorno desechable desde un tag de imagen en una URL name.cdn.com.tr, y lo desmantela cuando la revision termina.
Preguntas frecuentes
Container Apps construye mi imagen desde un Dockerfile?
No — despliega imagenes prearmadas. Tu construyes y subes la imagen a un registry (Docker Hub o uno privado) y le das a la plataforma la referencia de imagen y el puerto. Si quieres push-to-deploy desde el codigo fuente, combinalo con GitHub Deploy, que maneja el paso de build, o usa Docker Compose Instant Deploy para un stack multi-servicio de imagenes prearmadas.
Como funciona realmente aqui un deploy sin tiempo fuera de linea?
En un deploy nuevo la plataforma arranca el contenedor nuevo, espera a que tu ruta de healthcheck reporte listo, luego desplaza el trafico hacia el y retira el contenedor anterior. Si el contenedor nuevo nunca pasa su healthcheck, el trafico se queda en la version anterior, asi que un build roto no deja el servicio fuera de linea.
Mis secrets son visibles despues de guardarlos?
No. Los secrets se almacenan cifrados y se muestran solo por nombre de clave una vez guardados — los valores no se vuelven a mostrar en el panel, en logs, ni en previews. Eso te permite rotar un secret desde el panel sin que se filtre en una grabacion de pantalla, una sesion de soporte, o un log de build.
Mi contenedor puede alcanzar una base de datos administrada u object storage?
Si. Conectas una base de datos administrada, Redis, o un bucket de object storage a la app, y los detalles de conexion y access keys se inyectan como variables de entorno o secrets. El contenedor los lee de su entorno, asi que las credenciales nunca tienen que hornearse en la imagen.
Como corro mas de una instancia, y por que lo haria?
Define el numero de replicas en la app. Multiples replicas te dan resiliencia — si una se esta reiniciando o no esta saludable, las demas siguen sirviendo — y le permiten a la app manejar mas trafico concurrente. Combinado con rollouts controlados por salud, escalar hacia arriba no introduce una ventana en la que el servicio quede inalcanzable.
Puedo administrar container apps desde la linea de comandos y CI?
Si. La herramienta cdnctl realiza las mismas operaciones de deploy, escalado, logs, reinicio, y configuracion que el panel, asi que puedes scriptear operaciones de contenedores o correrlas desde un pipeline de CI en lugar de hacer clic en la interfaz. Tambien es la forma de previsualizar y aplicar una importacion de Docker Compose desde la terminal.