osFoundry / Platform
Serverless-Funktionen
Lambda-ähnliche Funktionen pro App – Cold-Start in 40 ms, keine Bereitstellung, Abrechnung pro Millisekunde.
Was es ist
Serverless-Funktionen in osFoundry sind Backend-Handler im Lambda-Stil, die zu genau einer App gehören. Wenn du im Workspace eine App baust, kannst du Funktionen anhängen, die serverseitige Logik ausführen: eine Formularübermittlung verarbeiten, eine externe API mit einem hinterlegten Schlüssel aufrufen, Daten transformieren, bevor sie den Client erreichen, und das alles, ohne selbst einen Server aufzusetzen oder zu betreiben. Es gibt nichts zu provisionieren: Du schreibst den Handler, deployst die App, und das Funktions-Backend kommt mit hoch. Der Cold Start liegt bei etwa 40 ms, sodass sich die erste Anfrage nach einer Leerlaufphase fast wie eine warme verhält, und abgerechnet wird pro Millisekunde Ausführung statt nach reservierter Kapazität, was bedeutet: Eine leerlaufende Funktion kostet nichts.\n\nInnerhalb von osFoundry werden Funktionen pro App-Installation provisioniert statt als ein gemeinsamer Pool, sodass jede App ihre eigene isolierte Ausführungsumgebung erhält, begrenzt auf die Daten und Secrets dieser App. Weil jede App außerdem ein eigenes Postgres-Schema pro Instanz mitbringt (CRUD, einen JSONB-Dokumentspeicher, Key-Value und pgvector), kann eine Funktion den Zustand ihrer App direkt lesen und schreiben, statt über eine Netzwerkgrenze zu einem separaten Datenbankdienst zu greifen. So bleiben Frontend, Backend-Logik und Daten einer App eine einzige deploybare Einheit innerhalb desselben Workspace, in dem du Chat, Agenten, Code und Wissen betreibst.\n\nDas ist wichtig, weil in einer kleinen App die meisten \"Backend-dazu\"-Momente genau der teure Teil sind: einen Host wählen, eine Runtime verdrahten, etwas warm halten und dafür zahlen, ob Traffic kommt oder nicht. Serverless-Funktionen pro App schrumpfen das auf das Deployen der App zusammen. Du behältst die BYOK-Haltung von osFoundry (deine eigenen API-Schlüssel, kein Reseller-Aufschlag auf die Modelle, die deine Funktionen aufrufen) und zahlst nur die Rechenzeit, die eine Funktion tatsächlich verbraucht, auf die Millisekunde gemessen.
Wichtige Funktionen
- Cold Start bei etwa 40 ms, sodass Anfragen fast warme Latenz erreichen, ohne dass du vorwärmst oder Instanzen am Leben hältst
- Kein Provisioning: Du schreibst die Funktion gegen deine App, deployst sie, und osFoundry fährt das Backend beim Deploy hoch
- Abrechnung pro Millisekunde tatsächlicher Ausführung, mit null Kosten, wenn eine Funktion im Leerlauf liegt
- Eine isolierte Funktionsumgebung pro App, begrenzt auf deren Daten und Secrets statt eines gemeinsamen Pools
- Greift mit dem pro Instanz mitgelieferten Postgres-Schema jeder App ineinander, sodass eine Funktion den Zustand direkt liest und schreibt
Anwendungsfälle
- App-Bauer: fügt einer Room-App einen Formular-Handler und eine geplante Datenbereinigung hinzu, ohne einen separaten Backend-Dienst aufzusetzen
- Einzelentwickler: ruft aus einer Funktion mit einem hinterlegten Schlüssel eine Drittanbieter-API auf, sodass das Secret nie ins Client-Bundle gelangt
- Datenorientiertes Team: lässt eine Funktion das mitgelieferte Postgres-Schema der App lesen und schreiben, um Datensätze zu aggregieren, bevor sie an die UI zurückgehen
Häufig gestellte Fragen
Wie hoch ist die Cold-Start-Latenz einer osFoundry-Serverless-Funktion?
Der Cold Start liegt bei etwa 40 ms, sodass die erste Anfrage an eine leerlaufende Funktion mit einer Latenz nahe dem warmen Pfad zurückkommt. Du musst Funktionen dafür weder vorwärmen noch eine Mindestzahl an Instanzen am Laufen halten.
Wie werden Serverless-Funktionen abgerechnet?
Abgerechnet wird pro Millisekunde tatsächlicher Ausführungszeit. Es gibt keine pauschale Monatsgebühr pro Funktion und keine Kosten im Leerlauf: Du zahlst nur die Rechenzeit, die eine Anfrage verbraucht. Modellaufrufe, die eine Funktion macht, laufen weiterhin über deine eigenen BYOK-Schlüssel, es gibt auf dieser Seite also keinen Reseller-Aufschlag.
Muss ich einen Server provisionieren oder betreiben?
Nein. Es gibt nichts zu provisionieren, zu skalieren oder am Leben zu halten. Du schreibst die Funktion gegen deine App und deployst die App; osFoundry fährt das isolierte Backend pro App für dich hoch. Jede App erhält ihre eigene Funktionsumgebung, begrenzt auf deren Daten und Secrets, und kann das mitgelieferte Postgres-Schema der App direkt lesen und schreiben.