Caso de Estudio Fundaia: una plataforma de despliegue construida desde cero

Toda factura de hosting gestionado tiene una línea que nadie mira: los servicios que llevaban todo el mes encendidos sin que les llamara nadie. Un entorno de staging, una herramienta interna, una demo para un cliente que dejó de entrar en marzo. Cuestan lo mismo que producción porque una plataforma gestionada cobra por un contenedor que existe, no por uno que trabaja. Fundaia es la plataforma de despliegue que construimos para dejar de pagar esa línea, y hoy ejecuta nuestra propia API en producción.

Estás Pagando por el Silencio

Cuando necesitas desplegar algo, la elección habitual tiene dos opciones y las dos son malas. Alquilas una plataforma gestionada, y la comodidad es real: conectas un repositorio y un dominio responde. Pero la factura crece con cada servicio que dejas encendido, la configuración vive en un panel que no es tuyo, y el día que quieres irte descubres que lo que se despliega ahí no se despliega en ningún otro sitio.

O cableas un servidor a mano. Es barato y es tuyo, y sigue siéndolo exactamente hasta el día en que la única persona que recuerda cómo se montó deja de estar. Entonces alguien necesita una base de datos junto a una API, caduca un certificado, un despliegue exige recargar un proxy, y lo que iba a costar una tarde se convierte en el motivo por el que los viernes no se despliega nada.

Ese es el hueco para el que se construyó Fundaia: la experiencia inicial de una plataforma gestionada, sobre una máquina cuyo coste, configuración y salida son tuyos.

Del Repositorio al Dominio, Sin Escribir Nada de Eso

Fundaia es una plataforma de despliegue. Conectas GitHub y eliges un repositorio; la plataforma lee el proyecto, deduce cómo debe construirse, escribe el Containerfile, construye la imagen, arranca un contenedor sin privilegios, espera a que responda a una comprobación de salud y publica la dirección. Las bases de datos vienen de una plantilla y se conectan solas, porque una variable apunta a otro servicio por referencia y no por valor, y la plataforma la resuelve en el despliegue. Y un servicio al que no llama nadie se duerme: la pasarela lo arranca de nuevo con la siguiente petición, así que un entorno parado deja de costar dinero sin dejar de funcionar.

Un Despliegue, Seis Pasos en Pantalla

Un despliegue no es una ruedecita girando y un resultado. Son seis etapas con nombre, cada una capaz de fallar por su cuenta y decirlo:

• 1. En cola: El despliegue se admite y espera su turno. Dos despliegues del mismo servicio nunca corren a la vez, así que un push mientras hay una construcción en marcha se encola en lugar de competir con ella.
• 2. Descargando el código: Se clona el repositorio en el commit que se está desplegando. El contexto de construcción se queda en la raíz del checkout, para que un lockfile o un paquete hermano por encima de la aplicación sigan resolviendo.
• 3. Construyendo la imagen: La plataforma detecta el stack y escribe el Containerfile, declarando un argumento de construcción por cada variable pública para que los valores lleguen al build. Si ese fichero lo editaste tú, no se sobrescribe nunca.
• 4. Arrancando el contenedor: El contenedor arranca sin privilegios y publica solo en loopback, en un puerto que asigna la plataforma. Nada de lo que expone es alcanzable desde la red salvo a través del túnel.
• 5. Comprobando que responde: El despliegue no está en marcha porque el proceso haya arrancado. Lo está cuando responde, que es la diferencia entre un servicio que se ha desplegado y un servicio que funciona.
• 6. En marcha: La dirección empieza a servir y el contenedor anterior se retira, liberando su nombre y su puerto. Su imagen se conserva, porque es la única vuelta atrás que no pasa por reconstruir.

Hecho Para una Máquina que Corre Sola

El flujo se lee sencillo. Lo que lo hace fiable es el conjunto de problemas que solo aparecen cuando hay tráfico y discos de verdad:

• Publicar un dominio es una escritura en base de datos, no recargar configuración: El proxy del borde se configura una vez, con una única regla comodín que reenvía todo lo que no reclame un host explícito. Publicar un servicio pasa a ser un insert: sin reescribir ficheros, sin recargas, sin permisos elevados y sin esperar a que converja nada.
• Escalado a cero que aguanta veinte visitantes a la vez: La forma obvia de despertar un servicio dormido, un cerrojo alrededor del arranque, serializa las peticiones y cada una sigue leyendo un estado obsoleto y arrancándolo otra vez. En su lugar las peticiones se deduplican, así que veinte visitantes comparten un arranque y diecinueve esperan a su resultado.
• Un disco que no se llena solo: Una imagen por despliegue es un sistema de ficheros entero, y una construcción multi etapa deja capas sin etiquetar que ninguna limpieza puede nombrar. Sin vigilancia eso llegó a 172 GB de un disco de 221 GB, con catorce imágenes realmente en uso. Un segador conserva las dos imágenes más recientes de cada servicio, para que un rollback tenga a dónde volver, y poda las capas intermedias pasado un corte para no matar nunca una construcción en curso.
• Ningún puerto abierto en el router: Un túnel sale desde la máquina, así que no hay nada que redirigir y la IP doméstica dinámica deja de importar. El TLS termina en el borde y el tráfico entra por loopback.
• La credencial de la plataforma nunca llega a un servicio desplegado: La cookie de sesión se escribe para el dominio padre, así que el navegador la ofrece a todos los servicios publicados por debajo. La pasarela la retira antes de reenviar: una línea, y un servicio desplegado nunca ve la credencial que administra la plataforma en la que corre.
• Una puerta de salida documentada: Los datos viven en volúmenes con copia diaria automática que se puede restaurar y descargar, y el Containerfile generado queda escrito y es editable. Lo que se despliega aquí se despliega en cualquier sitio que ejecute contenedores.

La Misma Plataforma, Operada de Cuatro Formas

La decisión interesante no fue construir la interfaz web. Fue negarse a construir las otras tres encima de ella. Las reglas viven una sola vez en los servicios, y cada superficie es una traducción de ellas en lugar de una capa sobre la anterior:

• La web, para el trabajo que es visual: Proyectos, servicios dibujados como un grafo con las variables que los conectan, registros de despliegue por etapa, métricas y facturación por servicio y por día.
• Una línea de comandos, para el trabajo repetitivo: Un binario en Rust que habla con cualquier instancia, no solo con una, con contrato JSON para automatizar. Un terminal no puede presentar una passkey, así que recibe credencial propia por un flujo de dispositivo: la plataforma imprime un código, tú lo apruebas en el navegador y el terminal recoge su token.
• Una API REST, para el trabajo que pertenece a tus sistemas: Todo lo que hace la interfaz es un endpoint, autenticado por proyecto, así que un despliegue se puede disparar desde tu propia tubería en lugar de desde un panel que alguien tiene que abrir.
• Un servidor MCP, para el trabajo que quieres delegar en un agente: La plataforma habla Model Context Protocol, así que un agente puede crear un proyecto, conectar una base de datos y desplegar un servicio. Alcanza exactamente lo que alcanza la persona cuyo token lleva, cada escritura queda en el historial de ese proyecto a su nombre, y ninguna herramienta que pueda llamar revela jamás un secreto.

Lo Que Entrega la Plataforma

• Un repositorio de GitHub corriendo sobre un dominio en marcha, con el Containerfile escrito por ti y editable por ti
• Bases de datos desde plantilla, conectadas por referencia para que ninguna dirección o credencial se copie a mano
• Servicios parados que se duermen y despiertan con la siguiente petición, para que un entorno que no usa nadie deje de costar dinero
• Memoria, CPU, volumen y salida medidos por segundo, mostrados por servicio y por día, con un techo de gasto que suspende en vez de sorprender
• Copias diarias restaurables y descargables, y vuelta a la imagen anterior sin reconstruir
• La misma capacidad desde la web, un terminal, una API y un agente, sin ningún puerto abierto en el router

Los Números Que Hay Detrás

Una plataforma que pierde el despliegue de alguien es peor que no tener plataforma, así que el listón de ingeniería está donde tiene que estar:

• React 19 y Tailwind CSS 4 en todas las pantallas, con los vídeos de producto escritos como componentes React para que no haya ningún fichero de vídeo que servir
• Bun como runtime, empaquetador y motor de tests, con TypeScript 7 fijado a una versión exacta porque el verificador de tipos es lo que decide si el código es correcto
• Podman para contenedores sin privilegios, una imagen por despliegue y un segador que decide cuáles sobreviven
• Un túnel de Cloudflare hacia fuera y un proxy local enrutando por nombre de host, con los contenedores de servicio solo en loopback
• Una línea de comandos propia en Rust, publicada y versionada aparte para que un CLI que no compila nunca frene un despliegue del servidor
• Más de 320 suites de tests automatizadas en el monorepo, y un despliegue que es un push a main: CI verifica el commit y la máquina lo instala preguntando, así que en GitHub no existe ninguna credencial de la máquina

¿Cuánto Te Cuesta Tu Infraestructura en Cosas Que No Puedes Cambiar?

Suma los servicios encendidos para nadie, la configuración que vive en el panel de otro y la migración que llevas posponiendo porque no sabes lo que costaría. Ese es el coste real, y ninguna de esas cosas aparece como una línea en la factura. Fundaia es lo que entendemos por construir infraestructura en lugar de alquilarla: una plataforma diseñada alrededor de un flujo operativo, llevada a estándares de producción, y alojando hoy nuestra propia API. Si estás eligiendo entre una factura que crece sola y un servidor que nadie quiere mantener, cuéntanos qué estás ejecutando. Nosotros te decimos qué haría falta para que fuera tuyo.

• Explora nuestros servicios de desarrollo de software a medida
• Lee el caso de estudio de recepción de mercancía de Almacén-Pro
• Cuéntanos qué estás ejecutando hoy