Runtime & Validator
An under-the-hood look at how your backend code runs safely and isolated, plus the automated checker that probes your live app. You never touch any of this to build or ship; it is documented for the curious.
This is an under-the-hood page
You do not need to understand any of this to build, refine, or ship apps. It all happens automatically. We document it here for the curious and for anyone who wants to reason about how their backend code is kept safe and isolated.Runtime Sandbox
When your app has backend code, that code runs in its own isolated space, walled off from every other app on GenMB. Nothing you build can reach another customer's app, and nothing they build can reach yours. This is handled for you; there is nothing to configure.
For the technically curious: backend code runs in an isolated process pool on a separate Cloud Run image, one process per tenant, recycled after idle to keep cost down. Caches, circuit breakers, and GCS-backed file storage are wired in for you. Python functions are AST-validated before execution, so imports of os, subprocess, socket, and ctypes are rejected. Network access and database calls go through the GenMB SDK helpers, not raw modules.
Validator
The validator is a Playwright-based probe that opens your deployed app, runs an interaction script (form submit, pagination, modal open/close), and reports back what worked and what crashed. The same probe powers App Health and the hourly heal cron.
Limits
- Function-host per-invocation timeout: 30 seconds.
- SSRF guard inside the validator blocks loopback and private hosts.
- Per-tenant process isolation; tenants cannot see each other's memory.
See Functions for the user-facing layer that runs on this runtime.
FAQs
Why is the runtime exposed in docs?▾
How is the runtime different from the function host?▾
Can I run untrusted code in the runtime?▾
Ready to build?
Create your first app for free, no credit card required.