Should you self-host Prefect server or pay for Prefect Cloud?
Self-host the open-source Prefect server when air-gapped operation or strict data-location rules apply and your team can run PostgreSQL, Redis and upgrades itself. Choose Prefect Cloud when SSO, SCIM, role-based access control and audit logs are mandatory and your workers can reach Prefect's API over the internet. In both models your flows run in your own infrastructure. The difference is where run metadata lives and who operates the control plane that records it. Prefect's own comparison notes that Cloud stores run metadata while workflows execute on your side, so the question is whether that metadata may leave your environment.
The self-hosted path requires you to operate the components that Cloud runs for you. The Prefect server bundles an API, a UI and a database that records flow and task state, logs, deployments, work pool status and automations. It uses SQLite by default and PostgreSQL for production, and multi-server deployments need PostgreSQL 14.9 or later, Redis for event messaging and a load balancer. Confirm those versions against the self-hosted Prefect documentation before you size the environment, and plan a rehearsed upgrade path, since new clients can be incompatible with old servers as the REST API gains fields. Also confirm that your identity provider and audit requirements can be met by your own controls, because the server documentation states that RBAC, audit logs and SSO are not included.
Prefect Cloud makes sense when those controlled features are a requirement rather than a preference. Prefect ties SSO and SCIM, granular team and object permissions, and audit logs to Cloud, and its pricing page places SSO on the Team plan and object-level RBAC on Enterprise. Ask Prefect for a written quote against your user count, deployment count and required audit log retention, because the Team plan's audit log window is shorter than many compliance programs expect. If your security team cannot accept outbound API polling from workers, the decision is already made: self-host.
How the two hosting models compare on features, plans and limits
This table sets the self-hosted Prefect server against the Prefect Cloud plans on where run metadata lives, which features are gated, and the limits each plan states. Read it as a checklist: a feature marked Cloud-only is one you cannot get from the open-source server, and plan limits should be confirmed on Prefect's pricing page before you budget.
| Factor | Self-hosted Prefect server (open source) | Prefect Cloud |
|---|---|---|
| Framework license | Prefect framework is Apache-2.0 licensed | Managed service built on the same Apache-2.0 framework |
| Where run metadata is stored | In a database you run, SQLite by default and PostgreSQL for production | Prefect Cloud stores run metadata; workflows still execute in your infrastructure |
| SSO and SCIM | No | Yes |
| Granular team, project and object permissions | No | RBAC from Team plan; object-level RBAC on Enterprise |
| Audit logs | No | Team plan includes a 24-hour audit log; longer retention on Enterprise |
| Users and deployments | Limited only by your own infrastructure and sizing | Hobby: 2 users, up to 5 deployments; Starter: 3 users, up to 20 deployments; Team: up to 100 deployments, billed per user |
| Uptime commitment | Uptime depends on your own servers, database and load balancer | Enterprise plan lists a 99.9% uptime SLA; confirm terms in the contract |
| Air-gapped or offline sites | Supported, because the server runs inside your network | Not suitable, since workers poll Prefect's API over the internet |
Why air-gapped sites must self-host Prefect
If your workflows run on networks with no route to the internet, plan on self-hosting open-source Prefect. Prefect's own comparison of Cloud and open source states that Prefect Cloud requires workers to poll Prefect's API over the internet, so an air-gapped deployment cannot depend on Cloud at all. The self-hosted Prefect server documentation describes the alternative: the API, UI and database all run inside your own environment, with the server's PostgreSQL database holding flow and task run state, logs, deployments and work pool status.
The split between Cloud and your infrastructure matters for classification and egress review. Prefect states that Cloud stores run metadata while workflows execute in your infrastructure. That means the data your flows touch stays where it is, but run metadata, and potentially logs and state, leave your boundary when you use Cloud. Your data classification policy should decide whether run metadata derived from regulated datasets (parameter values, error messages, task names, artifacts) may be stored outside your perimeter. Your egress review should list every outbound path a Cloud worker needs, and your security team should confirm that each path is approved before any worker is registered.
Before a regulated review, confirm the details with Prefect rather than relying on a summary. Ask which run fields Cloud stores, how long they are retained, where they are hosted, what encryption and access controls apply, and which API endpoints workers call. Get the answers in writing and tie them to the version of your deployment. If the answers do not fit your classification rules, the self-hosted path is the one to plan for, and your team should own the PostgreSQL, Redis (for multi-server setups) and upgrade work that comes with it.
Which compliance and access controls depend on the hosting model
Access control, audit logging, data location and identity integration do not behave the same on a self-hosted Prefect server as on Prefect Cloud. The cards below separate what Prefect reserves for Cloud from what your own environment must provide, and what each choice leaves for your auditors to assess.
Role-based access control
Prefect's comparison page ties granular team, project and object permissions to Prefect Cloud. A self-hosted server does not give you that model out of the box, so any separation between engineers, operators and approvers must be enforced by network placement, reverse-proxy authentication or separate server instances. Confirm in writing which permission model you will be relying on before you map roles to control objectives. Ask Prefect which Cloud tier includes object-level RBAC for your team count.
Single sign-on and SCIM provisioning
SSO and SCIM are tied to Prefect Cloud on the comparison page, and the pricing page places SSO from the Team plan and SCIM under Enterprise. A self-hosted server leaves login and user lifecycle to whatever gateway you place in front of it. Confirm how joiners, movers and leavers will be deprovisioned, because a removed employee must lose access to the UI and API, not only to the identity provider.
Audit log retention
Prefect's pricing page lists a 24-hour audit log on the Team plan. If your control set expects longer retention, you need either a self-managed log pipeline that captures API and UI activity from the self-hosted server, or confirmation from Prefect that a higher tier retains logs for the period you need. Decide the retention period with your auditor before choosing the plan, because a short Cloud window is a common reason teams move to self-hosting.
Data location and air-gapped sites
Prefect Cloud stores run metadata while workflows execute in your infrastructure, and its workers poll Prefect's API over the internet. For air-gapped networks, Prefect's own guidance is self-hosted open-source Prefect. For data residency reviews, map every category of run metadata, logs and artifacts to a region and a system owner, and check whether any task payload could leave your boundary through a Cloud connection.
Identity integration in self-hosted deployments
A self-hosted Prefect server does not bundle an identity provider, so authentication depends on the proxy, SSO gateway or directory you deploy beside it. Document which component issues sessions, how API tokens are issued and revoked for automation, and how service accounts used by workers are scoped. Each of these components becomes part of the system your auditors assess, along with its logs and change history.
Who issues the evidence
DeployOpen can prepare the access configuration, logging setup, data flow documentation and control evidence for your environment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies assess each environment separately, so a self-hosted deployment, a Cloud tenant and a hybrid setup each need their own evidence. Ask your auditor which artifacts they will sample before the build starts.
What a self-hosted Prefect server needs: PostgreSQL, Redis and a load balancer
A self-hosted Prefect server is not a single process. It bundles an API, a UI and a database, and the database is where the operational work sits. According to the Prefect server documentation, that database records flow and task run state, logs, deployments, concurrency limits, variables, artifacts, work pool status, events and automations. Losing or corrupting it means losing the run history your on-call and audit teams rely on, so the database choice is the first decision to make. Prefect server uses SQLite by default, which suits a single-user evaluation. For production, the PostgreSQL database is the expected choice, and that means your team owns its provisioning, backups, restore testing and patching, usually under the same controls you apply to other production PostgreSQL.
If you plan more than one API server for availability, the requirements grow. According to the self-hosted Prefect documentation, multi-server deployments need PostgreSQL 14.9 or later, Redis for event messaging and a load balancer in front of the API servers. Each of these is another component to deploy, monitor, secure and back up, and each runs inside your network, so none of it is covered by a vendor-managed service. Before you size the environment, confirm the exact PostgreSQL, Redis and load balancer versions and high-availability patterns your platform team supports, and check them against the current self-hosted Prefect guide. Cloud plans take these components off your hands, which is part of what you pay for.
Upgrades need a sequencing rule. The Prefect server documentation states that old clients work with new servers, but new clients can be incompatible with old servers because new fields are added to the REST API. Upgrade the server first, then the workers and flow-running environments, or pin client versions until every component is on a compatible release. Write this into your change process, test it in a non-production environment that mirrors your worker fleet, and keep a tested rollback path for the database schema. Ask your team to confirm how each Prefect release handles database migrations before scheduling any production change window.
What your team runs in each model
This table compares the recurring operating work for a self-hosted Prefect server against Prefect Cloud, where the vendor runs the control plane and your team still runs workers and infrastructure. Read each row as a question to ask your platform team, then request a written effort estimate based on your topology.
| Operating task | Self-hosted Prefect server | Prefect Cloud |
|---|---|---|
| Database backups and PostgreSQL versions | Your team backs up the PostgreSQL database that stores flow runs, deployments, logs and events, tests restores, and plans PostgreSQL version changes. Production use calls for PostgreSQL, and multi-server setups need version 14.9 or later. | Prefect operates the metadata store. Confirm with Prefect how backup, restore and recovery objectives are documented in your plan. |
| Redis for multi-server setups | Redis handles event messaging when you run more than one server, so your team operates, patches and monitors it alongside the API and UI. | No Redis to operate on your side. Prefect runs the event infrastructure behind the managed dashboard. |
| Load balancer and network paths | Your team configures and maintains the load balancer in front of multiple servers, along with TLS certificates and health checks. | Workers poll Prefect's API over the internet, so confirm your outbound network rules and proxy settings with your security team. |
| Server upgrades and client version coordination | Your team schedules server upgrades and tests them against client versions. Old clients work with new servers, but new clients can fail against old servers as new REST API fields are added, so upgrade order matters. | Prefect upgrades the hosted server. Your team still pins and upgrades workers and client packages, and should confirm the compatibility window in the vendor's release notes. |
| Monitoring and incident response | Your team monitors the API, UI, database, Redis and load balancer, and owns on-call response for each component. | Prefect monitors the hosted control plane. Your team monitors workers, work pools and the infrastructure that runs flows. |
| Workers, work pools and infrastructure | Your team runs and scales workers, work pools and the compute where flows execute, in the same way under both models. | Your team still runs workers, work pools and the compute where flows execute, because workflows run in your infrastructure under both models. |
| Identity and access administration | SSO, SCIM, granular RBAC and audit logs are not part of the self-hosted server, so your team manages access through its own controls and any external identity tooling. | SSO and SCIM, granular team and object permissions, and audit logs come with Prefect Cloud. Confirm which tier includes each feature before you plan user onboarding. |
| Effort estimate | Ask your implementation partner for a written effort estimate that covers your database, Redis, load balancer, upgrade cadence and on-call model. | Ask Prefect for the written plan tier and terms, then ask your partner to estimate the remaining worker and infrastructure work. |
Which hosting model fits which team
If workers cannot reach the internet, Prefect Cloud is not an option. Prefect's own comparison states that Cloud requires workers to poll Prefect's API over the internet, so air-gapped deployments should use self-hosted open-source Prefect. Many regulated sites also prefer that run metadata stay inside their boundary. Prefect states that Cloud stores run metadata while workflows run in the customer's infrastructure, so a self-hosted server keeps both under your control.
- Network path: Confirm that every worker and the server can reach each other without any outbound call to Prefect's API.
- Metadata location: Decide whether run state, logs and artifacts may leave your environment, since Cloud stores run metadata.
- Missing controls: The Prefect server documentation says RBAC, audit logs and SSO are not in the self-hosted server, so plan compensating controls at the platform level.
- Operating ownership: Assign a team to run the API, UI, database and upgrades, because you carry that work yourself.
- Evidence: Ask your auditor which controls they expect to see from the orchestrator itself before you design around the gap.
Confirm the network and data-residency rules with your security and compliance owners before choosing a hosting model.
Teams that must integrate identity with a corporate directory and provision users automatically usually look at Prefect Cloud. Prefect's comparison ties SSO and SCIM, granular team, project and object permissions and audit logs to Prefect Cloud. The self-hosted server does not provide these features, so identity integration is a deciding factor when you have central identity governance requirements.
- SSO from Team: Prefect's pricing page places SSO from the Team plan, which bills per user per month.
- SCIM and object permissions: Prefect's pricing page lists SCIM and object-level RBAC on Enterprise, so confirm which plan includes the exact feature you need.
- Recurring cost: Subscription fees recur per user on Team, so user growth directly changes the bill.
- Audit retention: The Team plan includes a 24-hour audit log, which may not match your retention rules.
- Vendor dependency: Your identity and audit trail then sit partly with a SaaS provider rather than only in your own infrastructure.
Confirm the current plan contents and the audit retention you need with Prefect's sales team before you rely on either.
Small teams with a few pipelines and little need for enterprise identity often start on the free or low-cost tiers. Prefect's pricing page lists Hobby as free with 2 users and up to 5 deployments, and Starter at $100 per month with 3 users and up to 20 deployments. Within those limits, the subscription can be simpler than running your own database and upgrade process, but the limits become the constraint as the team grows.
- Free limits: Hobby covers 2 users and up to 5 deployments, which suits a very small group with a short list of flows.
- Starter limits: Starter at $100 per month covers 3 users and up to 20 deployments.
- Self-hosted effort: A self-hosted server needs PostgreSQL for production, and multi-server setups also need Redis and a load balancer.
- Growth trigger: Moving to Team changes the price model to per user, so add up seats before you pass the limits.
- Migration cost: Switching later means moving deployments, work pools and any run history you want to keep.
Confirm your user count and deployment count for the next year before choosing a tier.
Platform groups that serve several business units often need separate workspaces and permissions that stop one team from changing another team's work. Prefect's pricing page places object-level RBAC and multiple workspaces on Enterprise, alongside SSO, RBAC and SCIM with a 99.9% uptime SLA. Enterprise pricing is custom, so the decision depends on a written quote rather than a list price.
- Workspace isolation: Multiple workspaces on Enterprise separate teams that would otherwise share one server.
- Object-level control: Confirm that object-level RBAC covers the deployments, work pools and automations your teams use.
- Uptime commitment: The stated 99.9% uptime SLA applies only to Enterprise, so self-hosting moves that responsibility to your team.
- Quote scope: Ask for pricing per user, per workspace and for support terms in writing.
- Self-hosted alternative: A self-hosted platform can isolate teams through separate deployments, but you then build and run that isolation yourself.
Confirm the exact isolation and SLA terms in the Enterprise contract before you size the platform team.
How to move between self-hosted Prefect and Prefect Cloud
This sequence shows how to move flows, work pools, workers and automations between a self-hosted Prefect server and Prefect Cloud without losing track of run history, permissions or audit evidence. It ends with a validated cutover that you can roll back if a check fails.
Inventory deployments, work pools and automations
The platform owner lists every deployment, work pool, work queue, variable, concurrency limit and automation on the self-hosted server, with its owning team and schedule. Record which flows depend on secrets, storage blocks or event triggers, because these need matching setup in Cloud. The step is done when the inventory is reviewed by the flow owners and each item is marked as move, rebuild or retire.
Confirm Cloud plan limits against inventory
Compare the inventory counts with the limits on the Prefect Cloud plan you are considering, including the number of users, deployments and the audit log window. The pricing page lists Hobby with 2 users and up to 5 deployments, Starter with 3 users and up to 20 deployments, and Team with up to 100 deployments and a 24-hour audit log. Ask Prefect in writing whether your deployment count and user count fit a plan, and whether Enterprise is needed for SSO, SCIM, object-level RBAC or a 99.9% uptime SLA. The step closes with a signed plan choice tied to the inventory.
Decide the fate of PostgreSQL and Redis history
Decide whether the existing PostgreSQL database, and the Redis instance used for event messaging in multi-server setups, will be retired, archived or kept for reference. Run history, logs, events and audit records recorded on the self-hosted server may not transfer directly into Prefect Cloud, so ask Prefect which export options exist before committing. Keep the database under backup and access control until the retention decision is written down and approved by your compliance owner. The step is done when the retention and deletion plan has an owner and a date set by your team.
Repoint workers and client configuration
The platform team updates the Prefect API URL and authentication settings in each client environment, CI job and worker, then points workers at the Cloud workspace. Workers in your own infrastructure poll Prefect's API over the internet, so confirm that outbound access is permitted and that air-gapped segments stay on self-hosted Prefect. Because new clients can be incompatible with old servers as the REST API adds fields, pin client and worker versions to a tested release during the change. The step is done when each worker shows as online in the target workspace.
Recreate access controls and automations in Cloud
Security and platform leads rebuild user groups, team and project permissions, and SSO or SCIM provisioning in the Cloud workspace, then recreate automations and notifications from the inventory. Map each old role to a Cloud permission and record the mapping, since the Cloud feature set differs from the self-hosted server. Test that a standard user can see only the projects they own. The step is done when the access matrix has been reviewed and signed off against the original inventory.
Validate runs and events in a parallel window
Run representative flows on both platforms for the same inputs, then compare run states, task outcomes, logs, retries, schedules and event-triggered automations. Check that scheduled runs fire at the expected times in the Cloud workspace and that failure notifications reach the right people. Keep a written list of any differences and the fix for each. The step is done when every critical flow has a matching result and each difference has an owner.
Decide the cutover window and rollback path
The change owner chooses a cutover window that avoids critical scheduled runs, then pauses deployments on the self-hosted server in order and switches schedules to Cloud. Agree the rollback steps in advance, including how to restore the self-hosted server and its database if validation fails. Confirm with the business owners that the window and the rollback criteria are accepted. The step is done when the cutover record, rollback plan and post-cutover checks are filed with the change ticket.
Questions buyers ask before choosing a Prefect hosting model
What drives the cost of self-hosting Prefect compared with paying per user for Cloud?
Self-hosting moves cost from a vendor subscription into your own infrastructure and staff time. Prefect's pricing page lists Team at $100 per user per month with up to 100 deployments and a 24-hour audit log, and Starter at $100 per month with 3 users and up to 20 deployments, so per-seat pricing grows with headcount on Cloud. The self-hosted open-source server carries no Prefect license fee, but you pay for the PostgreSQL database, Redis where you run multiple servers, a load balancer, compute, backups, monitoring and the engineering hours to upgrade and operate them. Per-user Cloud cost rises with every person who needs access, while self-hosted cost is driven mostly by infrastructure size and the time your platform team spends on it. Ask Prefect for current Enterprise terms if you need SSO, SCIM or RBAC, because those features are not in the open-source server.
Can a small team run the Prefect server without outside help?
A small team can run a single Prefect server without outside help if it has someone comfortable with Python services, containers, a relational database and routine upgrades. Prefect's self-hosted documentation says the server uses SQLite by default and PostgreSQL for production, so a lone development instance is simpler than a production deployment. Multi-server setups add PostgreSQL 14.9 or later, Redis for event messaging and a load balancer, which is where most small teams start needing an operator. The real test is whether someone owns on-call response, backup restores and version upgrades. If none of those people exist, consider a fixed-scope implementation with DeployOpen, which plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, or a retainer for ongoing support.
What does a self-hosted Prefect server need from my team day to day?
Plan for four recurring areas: the database, the message layer, upgrades and backups. The Prefect server stores flow and task run state, logs, deployments, concurrency limits, variables, artifacts, work pool status, events and automations in its database, so PostgreSQL needs sizing, monitoring, retention planning and tested restores. Redis carries event messaging in multi-server deployments and must be highly available if you rely on event-based automations. Upgrades need care because Prefect's documentation says old clients work with new servers, but new clients can be incompatible with old servers as fields are added to the REST API. Confirm your upgrade order for workers, clients and servers before you start. Check with Prefect which Python and client versions your server requires, since the README states Prefect requires Python 3.11 or later.
How long does it take to migrate from Prefect Cloud to a self-hosted server, and what drives it?
The timeline depends on scope, not on a fixed number, and no supplied fact gives a migration duration. The main drivers are how many deployments, work pools and automations you run, whether run history must move or can stay in Cloud, how many workers poll the API, and how much of your flow code depends on Cloud-only features. Flows built on plain Python run on either option, but the metadata and access controls do not move automatically. Workers on Cloud poll Prefect's API over the internet, so the cutover needs new workers pointed at the self-hosted server, with a rollback plan. Ask any implementation partner for a written scope that lists each workflow, environment and integration, and agree on the cutover window and acceptance tests before work starts.
Can Prefect Cloud be used in an air-gapped site?
No, Prefect Cloud cannot be used in an air-gapped site. Prefect's Cloud versus open source guidance says Prefect Cloud requires workers to poll Prefect's API over the internet, so air-gapped deployments should use self-hosted open-source Prefect. That makes self-hosting the required option for isolated networks, not a cost choice. You will need to plan the PostgreSQL database, any Redis instance, container images or packages, and upgrade media delivered through your own approved channels. Confirm with your security team how software and updates enter the enclave before selecting a version, and test the install path in a staging network that matches production restrictions.
Which Cloud-only features matter enough to pay for Prefect Cloud?
The features Prefect ties to Cloud are SSO and SCIM, granular team, project and object permissions, and audit logs. Prefect's pricing page places SSO from the Team plan, while object-level RBAC and multiple workspaces appear on Enterprise, and Enterprise includes SSO, RBAC, SCIM and a 99.9% uptime SLA. If your identity provider, access reviews or evidence collection depend on these controls, the self-hosted server will not supply them on its own. You can add authentication in front of the server through your own gateway, but confirm that approach with your security team, since it does not replicate Cloud's permission model. Ask Prefect to confirm which controls each plan includes at the time of purchase.
What should I ask for in a quote for a self-hosted Prefect deployment?
Ask for a written scope that separates one-time work from recurring work, because the two are priced differently. One-time items include architecture design, installation, PostgreSQL and Redis setup, identity integration, migration of flows and deployments, hardening, backup testing and documentation. Recurring items include upgrades, monitoring, on-call support and continuous testing, which are typically offered as retainers. Ask what is included in each deliverable, which environments are covered, how acceptance is measured, what the timeline depends on, and what the client must provide, such as cloud accounts, network access and named owners. Request a clear statement of what is excluded, including Prefect license fees if you move to Cloud Team or Enterprise. DeployOpen does not publish a price list and quotes follow the written scope.
Is the open-source Prefect server still actively maintained?
Yes, the open-source project is actively released. Prefect is Apache-2.0 licensed, and Prefect 3.8.8 was released on October 6, 2026, after 3.8.7 on September 26, 2026, according to the PrefectHQ/prefect GitHub releases page. The 2.x line still received 2.20.26 on September 2, 2026, so older deployments are not abandoned, but you should plan a move to the 3.x line on your own schedule. Check the release notes for breaking changes before each upgrade, and test them in a staging environment that mirrors your database and worker setup. Confirm Prefect's support expectations for each line directly with the vendor before relying on it.
How DeployOpen scopes and runs a self-hosted Prefect server
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For a Prefect decision, that means we start from where your workflows must run and which Cloud-only controls you actually need, then agree the self-hosted build in writing before any work begins.
How we scope
- Written scope lists which Prefect features, environments and teams the self-hosted server must support.
- We record whether SSO, SCIM, RBAC and audit logs are required, and how each would be met without Prefect Cloud.
- Scope names the target PostgreSQL, Redis and load balancer layout for each planned server environment.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the Prefect server, database and workers inside your cloud accounts, data centers or air-gapped network.
- We configure PostgreSQL as the production database and document the Redis event messaging setup for multi-server deployments.
- Work pools, workers and deployments are configured so flow code and run data stay within your infrastructure.
- Testing covers worker polling, failover behavior and upgrade paths before any environment is handed over.
How we hand over
- You receive documentation covering architecture, configuration, access controls and the upgrade procedure we agreed.
- We document backup and restore steps for the Prefect database, including how to verify a restore.
- Handover includes a walkthrough with your platform and security teams on running and monitoring the server.
- Compliance-relevant evidence, such as access settings and configuration records, is packaged for your own auditors.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade planning covers Prefect server and client version compatibility, so workers and servers stay in step.
- Retainer scope is agreed in writing, including which environments, upgrades and test cycles it covers.
- Ask any provider, including us, to confirm the support window and upgrade commitments in the written quote.
