osFoundry / Platform
Container compute
Need persistent processes? Flip the runtime to a container. Same app, different mode.
What it is
Container compute is a runtime mode for apps you build in osFoundry. Most apps run fine as short-lived, request-driven processes that spin up, answer, and shut down. But some workloads need something that stays alive: a WebSocket server holding open connections, a background worker draining a queue, a scheduler ticking on its own clock, or a backend that keeps warm state in memory between requests. For those, you flip the runtime to a container and the same app keeps running as a long-lived process instead of starting fresh each time.
The point is that it is the same app. You do not rewrite it, fork it, or move it to another service. The code, the routes, and the wiring stay put; you change how it executes. That makes container mode a decision you make when a feature needs it, not an architecture you commit to up front. Start an app in the lighter, ephemeral mode, and switch it to a container the moment you add the piece that has to persist.
This fits osFoundry's model of keeping chat, agents, apps, code, and data in one workspace rather than scattered across separate hosting accounts. Because osFoundry is bring-your-own-key and local-first, you are running your own app on your own terms without a per-seat SaaS wrapper around it. Container compute extends that to the backend: when your app graduates from a stateless helper into something that needs to stay running, the workspace already has a place for it to live.
Key capabilities
- Flip any osFoundry app between ephemeral and container runtime without changing its code
- Run long-lived processes: WebSocket servers, background workers, schedulers, and daemons
- Keep warm state in memory between requests instead of cold-starting every call
- Choose the runtime per app, so you only pay for a persistent process where a feature needs one
- Backend lives in the same workspace as your chat, agents, code, and data
Use cases
- Developer: an app added a WebSocket feature for live updates, so its runtime is switched to a container to hold connections open
- Automation builder: a background worker that drains a job queue and runs on a schedule needs a process that never sleeps
- Team lead: a prototype app started stateless and, once it needed a warm cache and a persistent backend, moved to container mode without a rebuild
Frequently asked questions
When should I switch an app to container compute instead of the default runtime?
Switch when your app needs something to stay alive between requests: open connections (like WebSockets), background or scheduled workers, a daemon process, or in-memory state you do not want to lose on every call. If the app just answers requests and shuts down, the lighter ephemeral runtime is the better fit.
Do I have to rewrite my app to run it as a container?
No. It is the same app in a different mode. You flip the runtime setting and the existing code runs as a persistent process. That is the whole idea, so you can start an app simple and only move to a container once a feature actually requires it.
How does this relate to osFoundry being bring-your-own-key and local-first?
Container compute is about where your app's backend runs, so it sits alongside the rest of osFoundry: your keys, your models, and your data stay under your control, and the app's backend lives in the same workspace as your chat, agents, code, and data instead of a separate hosting account.