Derek CalderónPegas la URL de un repositorio. Deploya hace el resto.
Deploya es una plataforma para publicar apps: toma un repositorio de GitHub, lo construye, lo corre en un contenedor aislado y lo deja en línea con HTTPS en su propio subdominio. Si algo sale mal, la versión anterior sigue sirviendo. Fui el arquitecto del equipo: diseñé el motor, la infraestructura y su camino en AWS.
De punta a punta: se valida el repositorio, avanzan las cinco etapas con su bitácora y la app responde en su subdominio.
Publicar una app no debería exigir saber de servidores.
Para poner una app en internet hay que saber Docker, un proxy inverso, certificados, límites de memoria y cómo volver atrás si algo falla. Quien solo quiere publicar su proyecto termina aprendiendo operaciones.
Las plataformas que lo resuelven son cerradas o cobran por app más de lo que paga un estudiante o un negocio pequeño. Y cuando una versión sale mala, volver a la anterior casi siempre significa construirla otra vez y esperar.
El curso pedía un producto completo, en equipo y con entregas evaluadas. Nos propusimos que Deploya fuera una nube pequeña de verdad: con planes, aislamiento entre clientes y un costo que cerrara las cuentas.
Una URL de entrada, una app en línea de salida.
A mano
- Construir la imagen y levantar el contenedor con comandos.
- Editar el proxy y sacar un certificado por cada dominio.
- Sin límites: una app puede comerse la memoria de todas.
- Volver atrás es reconstruir y cruzar los dedos.
Con Deploya
- Pegas la URL y Deploya detecta cómo construirla.
- Subdominio propio con HTTPS desde el primer despliegue.
- Cada app en su red, sin privilegios y con la CPU y memoria de su plan.
- Revertir reutiliza la imagen guardada y tarda segundos.
Dos meses de curso, y después a AWS.
Primero la spec
Cada historia se escribe como especificación antes de programarla, y cada decisión grande queda en un documento.
El motor
Cola de trabajos, construcción, contenedores con límites, rutas y, a mediados de octubre, la reversión sin reconstruir.
El producto
Planes y pagos simulados, métricas, administración y un modo para instalarlo en tu propio servidor.
Entrega final
Versión 1.0: todo el alcance del curso completo y el repositorio público.
Piloto en AWS
El servidor se crea con Terraform, la landing pasa a S3 y CloudFront, y la escala queda diseñada.
Lo que vive quien publica su app.
Pegas el repositorio y Deploya propone el resto.
Valida que el repositorio exista, lee la rama y el último commit, detecta si trae su Dockerfile o qué receta usar, y sugiere el nombre, el puerto y la dirección final. Las variables se guardan cifradas.
Recepción, construcción, ejecución, enrutamiento y operación.
Cada etapa avanza en pantalla con su bitácora en vivo. La app nueva recibe tráfico solo después de responder bien: hasta entonces, la versión anterior sigue atendiendo a sus visitantes.
Si la construcción falla, la app sigue en línea.
El error se explica en palabras claras, con la línea que falló, y el aviso dice qué versión sigue sirviendo. No quedan contenedores ni rutas a medias: cada paso sabe deshacerse.
Volver a una versión buena, sin construir otra vez.
Cada construcción deja una imagen que no cambia. Revertir la vuelve a encender con las variables y los límites de hoy, y no gasta las construcciones del plan.
Una rama rota falla, la versión 1 sigue en línea y se revierte con la imagen reutilizada.
Una arquitectura que crece sin que el costo se coma el margen.
Hoy Deploya corre como piloto en un solo servidor de AWS. La siguiente fase ya está diseñada: apps en ECS, construcciones en Fargate Spot y datos en servicios administrados. Lo que importa son los servicios, y por qué cada uno está ahí.
ECS sobre EC2 para las apps. Fargate Spot para construirlas.
Muchas apps pequeñas caben empacadas en pocos servidores, y las construcciones, que son cortas y queman CPU, corren aparte en máquinas que existen solo unos minutos. Sin Kubernetes y sin NAT, para no pagar por lo que no se usa.
- En línea hoyEl piloto en una EC2 y la landing en S3 + CloudFront, creados con Terraform.
- DiseñadaLa fase de escala del diagrama, en una decisión de arquitectura aún propuesta.
- CloudflareDNS del dominio
- NLBuna sola entrada
- Traefik en ECSelige la app por subdominio
- App en EC2Auto Scaling, 50 % Spot
- Web y APItareas ECS
- ElastiCache Valkeyencola el despliegue
- Workertoma el trabajo
- Fargate Spotconstruye y se apaga
- ECRguarda la imagen de la versión
- Fargate Spot
≈ US$0.0015 por construcciónCada despliegue se construye en una máquina que existe solo unos minutos. Spot cuesta alrededor de 69 % menos, y construir deja de quitarle CPU a las apps de los clientes. - ECS sobre EC2
≈ 57 apps por nodoEmpaca muchas apps pequeñas por memoria en cada servidor. Correr cada app en Fargate costaría de US$18 a 72 al mes, frente a un ingreso de US$1.5 por proyecto. - EC2 Auto Scaling
≈ US$1.25 por app al mesSuma servidores cuando el clúster se llena. Las apps de los planes de entrada pueden ir en Spot; las de Pro y Business, en servidores normales. - ECR
≈ US$1 al mesGuarda una imagen por versión. Revertir es apuntar a la imagen anterior: sin construir de nuevo. - NLB
≈ US$16.43 al mesUna sola puerta para cientos de subdominios. Un balanceador con una regla por app se quedaría corto a las 100 reglas. - ACM
gratisEl certificado comodín para todos los subdominios, en el NLB. La otra opción es mantenerlo en Traefik, como hoy. - RDS PostgreSQL
≈ US$23.36 al mesLa base de la plataforma sale del servidor de las apps. Una sola instancia compartida, no una por cliente. - ElastiCache Valkey
≈ US$9.34 al mesLa cola de despliegues. Con ella, varios workers se reparten el trabajo sin cambiar código. - CloudWatch Logs
≈ US$2.50 al mesBitácoras y métricas de cada app cuando ya no hay un solo servidor al que preguntarle. - CloudFront + S3
en línea · capa gratuitaLa landing sigue arriba aunque el clúster se caiga o se esté actualizando. - IAM
mínimo privilegioCada construcción corre sin las credenciales de la plataforma, con un rol que solo puede subir su imagen a ECR. - VPC sin NAT
≈ US$32.85 al mes menosServidores y construcciones en subredes públicas, con la entrada cerrada por el grupo de seguridad.
Un servidor que se recrea con un comando.
Para la presentación final bastaba un servidor, y había un día para montarlo. Lo hice con Terraform y los mismos archivos de Docker que usa el equipo en desarrollo: cero cambios de código, todo revisable en un pull request y dentro de los créditos de AWS.
- EC2Una m7i-flex.large (2 vCPU, 8 GB) en Ohio corre toda la plataforma. Es la única de 8 GB que entra en el plan gratuito, así AWS no cobra a la tarjeta.
- VPCRed propia con una subred pública, sin NAT, y solo los puertos 80 y 443 abiertos.
- Systems ManagerSe entra al servidor por Session Manager, sin abrir el puerto 22.
- EBSDisco cifrado, con un snapshot diario que se guarda una semana.
- AWS BudgetsAvisa al 50, 80 y 100 % de un tope de US$70, y antes si el pronóstico lo va a pasar.
- CloudFront, S3 y ACMLa landing, con su certificado, fuera del servidor de las apps.
Arquitecto de un equipo de cuatro.
Fui dueño del motor: la construcción, la orquestación de contenedores y el enrutamiento con HTTPS. También de los contratos entre módulos, de los diagramas y de las 12 decisiones de arquitectura del proyecto, y del servidor en AWS.
El resto del equipo llevó la identidad y el correo, los planes y pagos, los proyectos, la observabilidad y la interfaz web. El motor se diseñó con puertos: el producto no sabe si sus apps corren en Docker o en ECS, y por eso la fase de escala es escribir piezas nuevas, no reescribir el núcleo.
Diseño y dirijo; uso agentes de IA para acelerar la implementación. Cada cambio parte de una especificación escrita y de una decisión documentada, y los agentes trabajan sobre eso.
Una nube pequeña también tiene que cerrar las cuentas.
El panel nunca toca los contenedores.
La API solo deja el trabajo en una cola; un worker aparte es el único que construye y enciende contenedores. Un despliegue pesado no tumba el panel, y el permiso más delicado vive en un solo lugar.
El tráfico cambia solo cuando la app responde.
La ruta nueva se escribe después de comprobar que la app contesta. Un despliegue sin corte para los visitantes, y uno fallido no le quita nada a la versión que ya funcionaba.
Revertir no gasta nada.
Se guardan las cinco últimas imágenes. Volver atrás tarda segundos y no consume las construcciones del plan del cliente.
El piloto, en un día y dentro de los créditos.
ECS habría tomado semanas. Una EC2 con Terraform usó lo que ya funcionaba, con presupuesto vigilado y un costo de unos US$13 por los cinco días.
Fargate para construir, no para servir.
Una app encendida todo el mes en Fargate cuesta más que lo que paga su plan. Una construcción en Fargate Spot cuesta fracciones de centavo. Cada uno donde rinde.
Sin Kubernetes y sin NAT.
Solo el plano de control de EKS costaría unos US$73 al mes, y un NAT Gateway unos US$32.85. Para un equipo de cuatro, ECS da la escala sin esa cuenta ni esa operación.
Todo lo que pasa con una app, a la vista.
Las capturas y los videos se tomaron con el motor real en un equipo local: la construcción, los contenedores, el error de la rama rota y la reversión ocurrieron de verdad. La cuenta, los proyectos y las variables son ficticios, todos los proyectos usan la misma app de ejemplo y los pagos son los simulados del propio producto. En el video de punta a punta las etapas se pausaron unos segundos para que se vieran; en tiempo real duran menos. Los costos de AWS salen del modelo de costos del proyecto (precios de noviembre de 2026) y los de la fase de escala son estimaciones de su diseño.
→