osFoundry / Platform
Fonctions serverless
Fonctions de type Lambda par application — démarrage à froid en 40 ms, sans provisioning, facturées à la milliseconde.
Présentation
Les fonctions serverless d'osFoundry sont des handlers de backend façon Lambda rattachés à une seule app. Quand vous construisez une app dans le workspace, vous pouvez lui attacher des fonctions qui exécutent de la logique côté serveur : traiter l'envoi d'un formulaire, appeler une API externe avec une clé stockée, transformer des données avant qu'elles n'atteignent le client, le tout sans monter ni administrer le moindre serveur vous-même. Il n'y a rien à provisionner : vous écrivez le handler, vous déployez l'app, et le backend de la fonction se lève avec elle. Le démarrage à froid tourne autour de 40 ms, si bien que la première requête après une période d'inactivité se comporte presque comme une requête à chaud, et vous êtes facturé à la milliseconde d'exécution plutôt que sur de la capacité réservée, ce qui veut dire qu'une fonction inactive ne coûte rien.\n\nAu sein d'osFoundry, les fonctions sont provisionnées par installation d'app plutôt que sous forme d'un pool partagé unique : chaque app dispose ainsi de son propre environnement d'exécution isolé, limité aux données et aux secrets de cette app. Comme chaque app embarque aussi un schéma Postgres par instance (CRUD, un magasin de documents JSONB, clé-valeur et pgvector), une fonction peut lire et écrire l'état de son app directement, au lieu de franchir une frontière réseau vers un service de base de données distinct. Le frontend de l'app, sa logique de backend et ses données restent ainsi une seule unité déployable, dans le workspace même où vous faites tourner chat, agents, code et connaissances.\n\nCela compte parce que, dans une petite app, la plupart des moments « ajouter un backend » sont justement la partie coûteuse : choisir un hébergeur, câbler un runtime, garder quelque chose au chaud et le payer, que le trafic arrive ou non. Les fonctions serverless par app ramènent tout cela au simple déploiement de l'app. Vous conservez la posture BYOK d'osFoundry (vos propres clés d'API, aucune marge de revente sur les modèles que vos fonctions appellent) et vous ne payez que le calcul qu'une fonction consomme réellement, mesuré à la milliseconde.
Fonctionnalités clés
- Démarrage à froid d'environ 40 ms : les requêtes atteignent une latence quasi à chaud sans préchauffage ni instances maintenues en vie
- Aucun provisionnement : vous écrivez la fonction contre votre app, vous la déployez, et osFoundry lève le backend au moment du déploiement
- Facturation à la milliseconde d'exécution réelle, avec un coût nul quand une fonction reste inactive
- Un environnement de fonction isolé par app, limité aux données et aux secrets de cette app plutôt qu'à un pool partagé
- S'articule avec le schéma Postgres par instance livré avec chaque app, de sorte qu'une fonction lit et écrit l'état directement
Cas d’usage
- Créateur d'apps : ajoute un handler d'envoi de formulaire et un nettoyage de données planifié à une room app sans monter de service backend séparé
- Développeur indépendant : appelle une API tierce depuis une fonction à l'aide d'une clé stockée, si bien que le secret ne part jamais dans le bundle client
- Équipe axée données : exécute une fonction qui lit et écrit le schéma Postgres de l'app pour agréger des enregistrements avant de les renvoyer à l'UI
Questions fréquentes
Quelle est la latence de démarrage à froid d'une fonction serverless osFoundry ?
Le démarrage à froid tourne autour de 40 ms : la première requête vers une fonction inactive revient avec une latence proche du chemin à chaud. Vous n'avez pas besoin de préchauffer les fonctions ni de maintenir un nombre minimal d'instances actives pour atteindre ce chiffre.
Comment suis-je facturé pour les fonctions serverless ?
Vous êtes facturé à la milliseconde de temps d'exécution réel. Aucun forfait mensuel par fonction, aucun frais tant qu'elle reste inactive : vous ne payez que le calcul qu'une requête consomme. Les appels de modèle qu'effectue une fonction tournent toujours sur vos propres clés BYOK, il n'y a donc aucune marge de revente de ce côté.
Dois-je provisionner ou administrer un serveur ?
Non. Il n'y a rien à provisionner, à mettre à l'échelle ni à maintenir en vie. Vous écrivez la fonction contre votre app et vous déployez l'app ; osFoundry lève pour vous le backend isolé, propre à l'app. Chaque app obtient son propre environnement de fonction limité à ses données et à ses secrets, et peut lire et écrire directement le schéma Postgres livré avec l'app.