Skip to main content
Docs/Runtime & Validator
DocsRuntime & Validator
Free

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.

When the validator service is not configured (local dev), health probes silently no-op. Production deploys log a warning at startup so the misconfig is visible in logs rather than inferred from empty fields.

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?
You will not interact with it directly day-to-day. It is documented so you can reason about isolation, resource limits, and where your code actually executes when you ship.
How is the runtime different from the function host?
The runtime sandbox runs whole-app backends (your generated server code). The function host runs single-file Functions you author. Both share the same isolation model; they differ in what they execute and how lifecycle is managed.
Can I run untrusted code in the runtime?
The runtime is hardened to limit blast radius (no privileged syscalls, AST-restricted Python, network egress controls) but it is not a replacement for treating user-supplied code as untrusted. Generated code is YOUR code; the runtime keeps you safe from other tenants, not from yourself.

Ready to build?

Create your first app for free, no credit card required.