osFoundry / Platform
Cómputo en contenedor
¿Necesitas procesos persistentes? Cambia el runtime a un contenedor. Misma app, distinto modo.
Qué es
El cómputo en contenedor es un modo de ejecución para las apps que creas en osFoundry. La mayoría de las apps funcionan bien como procesos efímeros, guiados por peticiones: se levantan, responden y se apagan. Pero algunas cargas de trabajo necesitan algo que siga vivo: un servidor WebSocket que mantiene conexiones abiertas, un worker en segundo plano que vacía una cola, un planificador que marca su propio reloj o un backend que conserva estado caliente en memoria entre peticiones. Para eso cambias el modo de ejecución a contenedor y la misma app pasa a correr como un proceso de larga duración en lugar de arrancar de cero cada vez.
La clave es que se trata de la misma app. No la reescribes, no la bifurcas ni la mueves a otro servicio. El código, las rutas y el cableado se quedan donde están; solo cambias cómo se ejecuta. Eso convierte el modo contenedor en una decisión que tomas cuando una función lo pide, no en una arquitectura a la que te comprometes de antemano. Arranca una app en el modo ligero y efímero, y pásala a contenedor en el momento en que añadas la pieza que tiene que persistir.
Esto encaja con la idea de osFoundry de mantener el chat, los agentes, las apps, el código y los datos en un mismo espacio de trabajo, en vez de dispersos por cuentas de hosting separadas. Como osFoundry es bring-your-own-key y local-first, ejecutas tu propia app en tus propios términos, sin una capa SaaS de pago por asiento envolviéndola. El cómputo en contenedor extiende eso al backend: cuando tu app deja de ser un ayudante sin estado y necesita quedarse funcionando, el espacio de trabajo ya tiene un lugar donde alojarla.
Capacidades principales
- Cambia cualquier app de osFoundry entre ejecución efímera y en contenedor sin tocar su código
- Ejecuta procesos de larga duración: servidores WebSocket, workers en segundo plano, planificadores y demonios
- Conserva estado caliente en memoria entre peticiones en lugar de arrancar en frío en cada llamada
- Elige el modo de ejecución por app, así solo pagas por un proceso persistente donde una función lo necesita
- El backend vive en el mismo espacio de trabajo que tu chat, tus agentes, tu código y tus datos
Casos de uso
- Desarrollador: una app añadió una función WebSocket para actualizaciones en vivo, así que su ejecución pasa a contenedor para mantener las conexiones abiertas
- Creador de automatizaciones: un worker en segundo plano que vacía una cola de trabajos y corre según un calendario necesita un proceso que nunca duerma
- Líder de equipo: un prototipo empezó sin estado y, cuando necesitó una caché caliente y un backend persistente, pasó a modo contenedor sin reconstruir nada
Preguntas frecuentes
¿Cuándo conviene pasar una app a cómputo en contenedor en vez del modo por defecto?
Cámbialo cuando tu app necesite algo que siga vivo entre peticiones: conexiones abiertas (como WebSockets), workers en segundo plano o programados, un proceso demonio, o estado en memoria que no quieras perder en cada llamada. Si la app solo responde peticiones y se apaga, el modo efímero, más ligero, encaja mejor.
¿Tengo que reescribir mi app para ejecutarla como contenedor?
No. Es la misma app en otro modo. Cambias el ajuste de ejecución y el código existente corre como un proceso persistente. Esa es toda la idea: puedes empezar con una app sencilla y pasar a un contenedor solo cuando una función lo requiera de verdad.
¿Cómo se relaciona esto con que osFoundry sea bring-your-own-key y local-first?
El cómputo en contenedor tiene que ver con dónde corre el backend de tu app, así que va en línea con el resto de osFoundry: tus claves, tus modelos y tus datos siguen bajo tu control, y el backend de la app vive en el mismo espacio de trabajo que tu chat, tus agentes, tu código y tus datos, en lugar de en una cuenta de hosting aparte.