How would you choose between Prefect Cloud and a self-hosted Prefect server for a team?

## Start with what does not change People frame this as a security question and get it backwards. Under both options, Prefect's **hybrid model** holds: your flow code lives in your repository or image registry, your workers run in your infrastructure and poll the API outbound, and the data your flows touch never passes through Prefect. Results, when persisted, go to storage you configure. What the control plane sees is orchestration metadata — deployment definitions, run states and timings, parameters, tags, and logs your flow emits through the Prefect logger. That last list is the actual privacy question, and it is a real one: parameters and log lines can carry sensitive values if your code puts them there. But it is a much narrower question than "does my data go to a vendor". ## What self-hosting means operationally `prefect server start` runs the API and UI. For anything beyond a laptop you point it at **Postgres** rather than the default embedded database, and then you own the usual list: high availability for the API, connection pooling and sizing under a busy scheduler, backup and restore of the orchestration database, version upgrades coordinated with worker and client versions, TLS termination, and authentication in front of the UI and API. The open-source server does not come with per-user identity, roles or SSO out of the box, so multi-team access control is something you build around it — typically a reverse proxy and network boundaries, which is coarse. The honest cost is not the cluster resources; it is that someone must be on call for the orchestrator itself. An orchestrator outage does not corrupt anything — workers just cannot fetch work, and runs go `Late` — but it is a stop-the-world event for every pipeline. ## What Cloud adds - **A managed control plane.** Availability, upgrades and the database are Prefect's problem. - **Workspaces** — hard boundaries between teams or environments, with deployments, pools and secrets scoped inside one. - **RBAC, SSO and audit logging** — identity-level access control, which the open-source server does not provide natively. For an organization with compliance obligations this is often the deciding item. - **Push work pools** — Prefect Cloud submits runs directly to serverless compute (Cloud Run, ECS, ACI, Modal) using credentials you store, with **no worker to run**. This inverts one part of the hybrid model: you hand Cloud the ability to launch workloads in your account. That tradeoff is the thing to name explicitly in an interview. - **Managed work pools** — Prefect runs the flow on infrastructure it operates. Fastest possible start, least control, and now the code does execute outside your perimeter. - **Service accounts and API keys** with lifecycle management for CI. ## How to actually decide Ask four questions in order. **1. Can metadata and logs leave the perimeter?** If a regulator or an internal rule says no, self-hosting is the answer and the rest is moot. If you almost qualify, the mitigation is disciplined: never log secrets, never pass credentials as flow parameters, reference blocks instead. **2. Do you have a platform team?** Running a stateful service well is a standing commitment. A data team of four with no platform support that self-hosts will discover the orchestrator has become their most fragile dependency. A company already operating Postgres and Kubernetes fleets absorbs it easily. **3. How many teams share it?** One team, one environment: network-level isolation on a self-hosted server is adequate. Several teams that must not see or trigger each other's deployments: you need workspaces and role-based access, and rebuilding those around an open-source server is not a good use of anyone's quarter. **4. What execution model do you want?** If serverless push pools or managed execution are the reason you chose Prefect — no worker fleet at all — that decides it, because those are Cloud-only. If you are running Kubernetes workers anyway, the marginal benefit shrinks. ## Migration and hedging The reassuring part is that the choice is reversible in the direction that matters. Deployments are defined in `prefect.yaml` or Python in your repository, code lives in git or images, and work pools are recreated with a couple of CLI commands. Moving control planes means re-running your deployment step against a different `PREFECT_API_URL` and restarting workers; what you lose is historical run data, not capability. Keeping deployment definitions in version control rather than clicking them into a UI is what preserves that option — which is the general principal-level point: pick for today's operating capacity, and keep the artefacts portable so the decision can be revisited. ## Version note Describes Prefect 3.x. Feature availability on Cloud tiers changes over time; verify current specifics rather than quoting a plan.