El problema: una imagen que funciona no es un servicio en ejecución
Tener una API que se construye limpiamente en una imagen de contenedor es el 20 por ciento fácil; llevarla a producción es el otro 80. Tradicionalmente eso significa alquilar una VM, instalar un runtime, configurar un reverse proxy, obtener y renovar certificados TLS, abrir los puertos correctos, agregar un process manager para que la app reinicie tras un crash, conectar la recolección de logs, y montar guardia contra atacantes que encuentran la caja horas después de que esté en línea. Cada uno de esos pasos es trabajo de infraestructura indiferenciado que no tiene nada que ver con el trabajo real de tu API, y cada uno es un lugar para equivocarse sutilmente en seguridad o confiabilidad. Container Apps existe para colapsar toda esa lista en unos pocos campos.
Cómo lo resuelve cdn.com.tr: contenedores administrados detrás del edge
Le das a la plataforma una imagen, un puerto, y un healthcheck, y ella corre el contenedor, enruta tráfico hacia el a través del edge, y lo mantiene vivo. El TLS lo maneja Auto SSL, el punto de entrada público es la ruta edge en lugar del contenedor crudo, y el WAF filtra tráfico malicioso antes de que llegue a tu servicio. La configuración llega como variables de entorno y secrets inyectados en tiempo de ejecución, el escalado es un número de réplicas que defines, y los logs y el status se muestran en el panel. El resultado es que lo único de lo que eres responsable es de tu imagen de aplicación; las preocupaciones de servidor, proxy, certificado, y firewall las absorbe la plataforma.
Healthchecks: la red de seguridad del deploy
El healthcheck es lo que convierte un deploy de una esperanza en una operación controlada. Cuando lanzas una versión nueva, la plataforma arranca el contenedor y sondea tu endpoint de salud, y solo enruta tráfico a la instancia nueva una vez que ese endpoint reporta saludable. Un build que crashea al arrancar, no puede alcanzar su base de datos, o le falta un secret requerido falla la verificación y no se pone en rotación, así que un deploy roto se atrapa en el rollout en lugar de en tus usuarios. Por eso el healthcheck debería verificar disponibilidad real — dependencias alcanzables, configuración presente — en lugar de simplemente devolver 200 incondicionalmente. Un healthcheck significativo es la diferencia entre redeploys seguros y interrupciones silenciosas.
Entorno vs. secrets: configuración sin fugas
Las APIs necesitan configuración — URLs de base de datos, claves de terceros, feature flags — y la forma incorrecta de proveerla es hornearla en la imagen o comitearla al repositorio, donde vive para siempre en capas e historial. La plataforma separa las variables de entorno simples de los secrets: la configuración no sensible entra como entorno, mientras que contraseñas, tokens, y API keys se almacenan como secrets y se inyectan en tiempo de ejecución por clave, nunca se muestran de vuelta ni se escriben en tu build. Esto significa que la misma imagen puede moverse entre entornos con configuración diferente, tus credenciales se mantienen fuera del control de versiones, y rotar un secret es una acción de plataforma en lugar de una carrera de rebuild-y-redeploy.
Escalado, logs, y el ciclo operativo
Una vez que la API está en vivo, correrla es cuestión de unos pocos controles en lugar de administración de servidor. Eliges un plan de recursos y defines cuántas réplicas correr, escalando hacia arriba para un lanzamiento o un pico de tráfico y hacia abajo después. Los logs se transmiten en el panel para que puedas rastrear una solicitud, depurar un 500, o confirmar que un deploy realmente se aplico, y el status te muestra si el servicio está saludable y cuando se reinicio por última vez. Cada redeploy pasa por la misma verificación de healthcheck, así que lanzar un build nuevo es una acción repetible y observable — subes la imagen, observas que la verificación pase, y confirmas en los logs, sin nunca hacer SSH a nada.
Conectando storage y datos
La mayoría de las APIs necesitan algún lugar para guardar estado, y el servicio compone limpiamente con el resto de la plataforma para eso. Puedes conectar un bucket de Object Storage al contenedor como variables de entorno para que lea y escriba medios o documentos directamente, y puedes conectar una base de datos administrada o Redis para que el servicio tenga persistencia y caché sin que tampoco operes esos. Como estos se conectan a través de la plataforma y se entregan como configuración inyectada, la API se mantiene como una imagen sin estado que se puede escalar y redesplegar libremente mientras sus datos viven en servicios administrados a su lado.
Cómo configurarlo, paso a paso
Apunta a tu imagen
En el panel crea una Container App y referencia tu imagen prearmada (por ejemplo myorg/api:1.4) desde un registry público o privado. Para imágenes privadas, agrega una credencial de registry una vez para que la plataforma pueda extraerla. Define el puerto en el que escucha tu API para que el edge sepa a donde enviar el tráfico.
Define el healthcheck
Dale a la app una ruta de healthcheck como /health o /ready que devuelva 200 solo cuando el servicio realmente pueda servir. Esto es lo que la plataforma usa para decidir si un deploy nuevo está saludable antes de que reciba tráfico, así que hazlo verificar las cosas que realmente importan, como la conectividad a la base de datos.
Define entorno y secrets
Agrega configuración no sensible como variables de entorno y valores sensibles — API keys, contraseñas de base de datos, tokens — como secrets, para que se inyecten en tiempo de ejecución en lugar de hornearse en la imagen o comitearse a tu repositorio. Los valores de secrets se almacenan de forma segura y se referencian por clave, nunca se vuelven a mostrar.
Despliega y observa el healthcheck
Dispara el deploy desde el panel o con cdnctl. El contenedor se inicia, el healthcheck se sondea, y el servicio se marca listo — y solo se pone en rotación — una vez que pasa, así que un build roto no toma tráfico silenciosamente.
Conecta un dominio con Auto SSL y WAF
Expón el servicio para obtener una URL gratuita name.cdn.com.tr con HTTPS automático, o conecta tu propio dominio y deja que Auto SSL emita el certificado. Activa el WAF para que la API se ubique detrás del filtrado edge, y el contenedor origin solo es accesible a través de esa ruta edge.
Escala y observa
Ajusta el plan de recursos y el número de réplicas para la carga que esperas, y usa logs y status para observar deploys, reinicios, y comportamiento en tiempo de ejecución. Los redeploys siguen el mismo camino controlado por healthcheck, así que lanzar una versión nueva es una operación rutinaria y observable.
Escenarios de ejemplo
Una API JSON se publica desde su imagen detrás de un dominio con Auto SSL y WAF, dándole al frontend un endpoint HTTPS estable y asegurado sin ningún servidor que mantener.
Un receptor de webhooks, un procesador de imágenes, o un servicio de auth corre de forma aislada con su propio escalado y secrets, desplegado y redesplegado independientemente de todo lo demás.
Un equipo de producto levanta un contenedor desde un tag de imagen para obtener una URL HTTPS compartible para una demo, y luego lo desmantela o redespliega a medida que avanza el build.
Preguntas frecuentes
La plataforma construye mi imagen, o yo traigo una?
Traes una imagen prearmada de un registry. Container Apps corre y enruta la imagen que proporcionas; si es privada, agregas una credencial de registry una vez para que la plataforma pueda extraerla durante el deploy.
Qué pasa si mi deploy nuevo está roto?
Falla el healthcheck y no se pone en rotación, así que el tráfico sigue yendo a la versión que funciona. Un contenedor que crashea al arrancar o no puede alcanzar sus dependencias se atrapa en el rollout en lugar de servir errores a tus usuarios.
Cómo mantengo las API keys y contraseñas de base de datos fuera de mi código?
Guárdalas como secrets, que se inyectan en el contenedor en tiempo de ejecución por clave y nunca se hornean en la imagen ni se comitean a tu repositorio. La configuración no sensible entra como variables de entorno simples, así que la misma imagen corre en entornos diferentes con configuración diferente.
Mi API puede alcanzar una base de datos o un bucket de Object Storage?
Si. Puedes conectar un bucket de Object Storage al contenedor como variables de entorno y conectar una base de datos administrada o Redis, así que el servicio tiene storage, persistencia, y caché mientras se mantiene como una imagen sin estado y redesplegable.
Cómo manejo un pico de tráfico?
Sube el número de réplicas y, si hace falta, el plan de recursos de la app. Como el tráfico entra a través del edge y los contenedores se ubican detrás de el, escalas el número de instancias para ajustar a la carga y vuelves a escalar hacia abajo después.
Puedo desplegar desde la línea de comandos en lugar del panel?
Si. cdnctl maneja las mismas operaciones de contenedores desde tu terminal — desplegar, redesplegar, escalar, e inspeccionar — así que puedes scriptear deploys o correrlos desde CI obteniendo el mismo comportamiento controlado por healthcheck que el panel.