Architecture

The Rebase control plane owns workspace scoping, source snapshots, immutable target versions, run records, and SDK polling. User code selects mode (interactive or job) and interactive isolation (shared or dedicated); the platform maps those semantics to Cloud Run infrastructure. The resolved path is recorded as execution_backend.

Function and model runs dispatch directly from the API layer. Interactive/shared invokes the shared runner with no per-function provisioning. Interactive/dedicated invokes a private service with tagged immutable revisions. Job mode starts one Cloud Run Job execution per run.

Workflow runs remain Prefect-backed. Rebase runs a self-hosted Prefect API on Cloud Run; the SDK compiles step calls into a stored step_graph, and the runner executes that graph as Prefect tasks. Interactive workflows are claimed by a warm shared worker; job workflows get one Cloud Run Job per run. A schedule does not change this — scheduled workflows use their configured mode.

That distinction matters operationally. Every interactive workflow executes as a child process of the Prefect worker container, so a memory-heavy step can kill the shared instance. Set mode="job" on workflows whose memory is large or unpredictable; the per-run job gives them their own container, limits, and infrastructure timeout — and, with memory= / cpu=, limits you choose rather than the backend default. Those two arguments require mode="job" for exactly this reason: an interactive workflow has no container of its own to size, so a limit declared there is refused at deploy time rather than accepted and quietly ignored.

All execution paths are Cloud Run. The former Modal, GKE-Prefect, and Prefect Cloud routes have been removed.