osFoundry / Platform
Calcul en conteneur
Besoin de processus persistants ? Basculez le runtime en conteneur. Même application, mode différent.
Présentation
Le calcul en conteneur est un mode d'exécution pour les apps que vous construisez dans osFoundry. La plupart des apps tournent très bien comme des processus éphémères, pilotés par les requêtes : ils démarrent, répondent et s'arrêtent. Mais certaines charges de travail ont besoin de quelque chose qui reste en vie : un serveur WebSocket qui maintient des connexions ouvertes, un worker en arrière-plan qui vide une file, un planificateur qui bat à son propre rythme, ou un backend qui garde un état chaud en mémoire entre les requêtes. Pour cela, vous basculez le mode d'exécution en conteneur et la même app continue de tourner comme un processus durable au lieu de repartir de zéro à chaque fois.
Ce qui compte, c'est que c'est la même app. Vous ne la réécrivez pas, ne la forkez pas et ne la déplacez pas vers un autre service. Le code, les routes et le câblage restent en place ; vous changez seulement la façon dont elle s'exécute. Le mode conteneur devient ainsi une décision que vous prenez quand une fonctionnalité l'exige, pas une architecture à laquelle vous vous engagez d'emblée. Lancez une app dans le mode léger et éphémère, et passez-la en conteneur au moment où vous ajoutez la pièce qui doit persister.
Cela s'inscrit dans l'approche d'osFoundry : garder le chat, les agents, les apps, le code et les données dans un même espace de travail plutôt que dispersés sur des comptes d'hébergement séparés. Parce qu'osFoundry est bring-your-own-key et local-first, vous exécutez votre propre app selon vos propres règles, sans couche SaaS facturée au siège qui l'enveloppe. Le calcul en conteneur étend cela au backend : quand votre app passe d'un simple assistant sans état à quelque chose qui doit rester en marche, l'espace de travail a déjà un endroit où le loger.
Fonctionnalités clés
- Faites passer n'importe quelle app osFoundry de l'exécution éphémère au conteneur sans toucher à son code
- Exécutez des processus durables : serveurs WebSocket, workers en arrière-plan, planificateurs et démons
- Gardez un état chaud en mémoire entre les requêtes au lieu d'un démarrage à froid à chaque appel
- Choisissez le mode d'exécution par app, pour ne payer un processus persistant que là où une fonctionnalité l'exige
- Le backend vit dans le même espace de travail que votre chat, vos agents, votre code et vos données
Cas d’usage
- Développeur : une app a ajouté une fonctionnalité WebSocket pour les mises à jour en direct, son exécution passe donc en conteneur pour garder les connexions ouvertes
- Créateur d'automatisations : un worker en arrière-plan qui vide une file de tâches et tourne selon un planning a besoin d'un processus qui ne dort jamais
- Chef d'équipe : un prototype a démarré sans état puis, lorsqu'il a eu besoin d'un cache chaud et d'un backend persistant, est passé en mode conteneur sans reconstruction
Questions fréquentes
Quand faut-il faire passer une app au calcul en conteneur plutôt qu'au mode d'exécution par défaut ?
Basculez lorsque votre app a besoin que quelque chose reste en vie entre les requêtes : des connexions ouvertes (comme les WebSockets), des workers en arrière-plan ou planifiés, un processus démon, ou un état en mémoire que vous ne voulez pas perdre à chaque appel. Si l'app se contente de répondre aux requêtes et de s'arrêter, l'exécution éphémère, plus légère, convient mieux.
Dois-je réécrire mon app pour l'exécuter en conteneur ?
Non. C'est la même app dans un autre mode. Vous basculez le réglage d'exécution et le code existant tourne comme un processus persistant. C'est tout l'intérêt : vous pouvez démarrer une app simple et ne passer en conteneur que lorsqu'une fonctionnalité l'exige vraiment.
Quel est le lien avec le fait qu'osFoundry soit bring-your-own-key et local-first ?
Le calcul en conteneur concerne l'endroit où tourne le backend de votre app, il s'aligne donc avec le reste d'osFoundry : vos clés, vos modèles et vos données restent sous votre contrôle, et le backend de l'app vit dans le même espace de travail que votre chat, vos agents, votre code et vos données, plutôt que sur un compte d'hébergement séparé.