osFoundry / Platform
Calcolo in container
Servono processi persistenti? Cambia il runtime in container. Stessa app, modalità diversa.
Che cos’è
Il container compute è una modalità di runtime per le app che costruisci in osFoundry. La maggior parte delle app funziona benissimo come processi effimeri, guidati dalle richieste: si avviano, rispondono e si spengono. Ma alcuni carichi di lavoro hanno bisogno di qualcosa che resti in vita: un server WebSocket che tiene aperte le connessioni, un worker in background che svuota una coda, uno scheduler che scandisce il proprio orologio, o un backend che mantiene stato caldo in memoria tra una richiesta e l'altra. In quei casi porti il runtime a container e la stessa app continua a girare come processo di lunga durata, invece di ripartire da zero ogni volta.
Il punto è che è la stessa app. Non la riscrivi, non ne fai un fork, non la sposti su un altro servizio. Codice, route e cablaggio restano dove sono; cambi solo come viene eseguita. Questo rende la modalità container una decisione che prendi quando una funzionalità la richiede, non un'architettura su cui ti impegni in partenza. Avvia un'app nella modalità leggera ed effimera e passala a container nel momento in cui aggiungi il pezzo che deve persistere.
Tutto ciò si sposa con l'idea di osFoundry di tenere chat, agenti, app, codice e dati in un unico workspace, anziché sparsi su account di hosting separati. Poiché osFoundry è bring-your-own-key e local-first, esegui la tua app alle tue condizioni, senza uno strato SaaS a pagamento per postazione che la avvolge. Il container compute estende questo al backend: quando la tua app cresce da semplice aiutante senza stato a qualcosa che deve restare in esecuzione, il workspace ha già un posto dove farla vivere.
Funzionalità principali
- Passa qualsiasi app osFoundry dal runtime effimero a quello a container senza toccarne il codice
- Esegui processi di lunga durata: server WebSocket, worker in background, scheduler e daemon
- Mantieni stato caldo in memoria tra le richieste invece di fare cold start a ogni chiamata
- Scegli il runtime per singola app, così paghi un processo persistente solo dove una funzionalità lo richiede
- Il backend vive nello stesso workspace di chat, agenti, codice e dati
Casi d’uso
- Sviluppatore: un'app ha aggiunto una funzione WebSocket per gli aggiornamenti in tempo reale, quindi il suo runtime passa a container per tenere aperte le connessioni
- Costruttore di automazioni: un worker in background che svuota una coda di job e gira su pianificazione ha bisogno di un processo che non dorme mai
- Team lead: un prototipo è partito senza stato e, quando ha avuto bisogno di una cache calda e di un backend persistente, è passato alla modalità container senza ricostruire nulla
Domande frequenti
Quando conviene passare un'app al container compute invece del runtime predefinito?
Passa quando la tua app ha bisogno che qualcosa resti in vita tra le richieste: connessioni aperte (come i WebSocket), worker in background o pianificati, un processo daemon, o stato in memoria che non vuoi perdere a ogni chiamata. Se l'app si limita a rispondere alle richieste e a spegnersi, il runtime effimero, più leggero, è la scelta migliore.
Devo riscrivere la mia app per eseguirla come container?
No. È la stessa app in una modalità diversa. Cambi l'impostazione del runtime e il codice esistente gira come processo persistente. È tutto qui: puoi partire con un'app semplice e passare a un container solo quando una funzionalità lo richiede davvero.
Come si collega tutto questo al fatto che osFoundry sia bring-your-own-key e local-first?
Il container compute riguarda dove gira il backend della tua app, quindi si affianca al resto di osFoundry: le tue chiavi, i tuoi modelli e i tuoi dati restano sotto il tuo controllo, e il backend dell'app vive nello stesso workspace di chat, agenti, codice e dati, invece che su un account di hosting separato.