Service Accounts are not included on the Team plan. They’re available on Pro and Enterprise plans. You can compare plan features here: prefect.io/pricing If you want to check upgrade options, that’s self-serve in Prefect Cloud at: app.prefect.cloud → Org Settings → Billing → Upgrade

You're right to call that out — the earlier answer was incorrect. Current best answer: Team plan does include Service Accounts. What I found: - The pricing page lists Service accounts under Team: prefect.io/pricing - Prefect docs also indicate service accounts are available for Team, Pro, and Enterprise in at least one current guide: Use the Prefect MCP server There is a docs inconsistency: - This page still says service accounts are for Pro and Enterprise: API keys guide So the most likely situation is: - Team supports service accounts - The API keys doc appears outdated - A possible caveat is that advanced permission scoping/read-only restrictions may be limited to Pro/Enterprise, while Team still has access to service accounts generally If you're deciding whether to upgrade, I would treat the pricing page as the stronger source for plan entitlements: prefect.io/pricing If you want, I can also help you verify exactly how service accounts behave on Team (for example, whether they support read-only or custom-scoped permissions).

For your use case, the safest interpretation is: - Team plan service accounts appear to exist - Granular/read-only permission scoping appears to be limited to Pro/Enterprise - So on Team, you should not expect custom/read-only scoping for a service account What the docs suggest: - This page indicates Team/Pro/Enterprise can use service accounts: Use the Prefect MCP server - And it specifically notes that Pro and Enterprise users can restrict service accounts to read-only access - The service account/API key docs are still inconsistent with that: API keys guide So the likely model is: - Team: service accounts available, but no granular scoping - Pro: service accounts + role-based scoping/read-only restrictions - Enterprise: service accounts + the most flexible/custom role controls For your GitHub Actions deployment case: -

prefect deploy --all

definitely needs write/deploy access, not read-only - On Team, if service accounts are available, the available evidence suggests they would not be custom-scoped down to a narrow deploy-only permission set - In other words, Team likely gives you a service account token you can use for CI/CD, but without fine-grained permission tuning I also verified the CLI command exists as expected:

prefect deploy --help

So if your only question is “can a Team-tier service account be used by GitHub Actions to run deploys?” the answer is probably yes. If your question is “can I scope that Team-tier service account to just the minimum deploy/write permissions?” the answer appears to be no — that’s likely Pro/Enterprise-only. Because the docs are still contradictory, if this upgrade decision hinges on least-privilege scoping, the best self-serve source is still: prefect.io/pricing And for anything plan-entitlement-specific beyond the published pricing matrix: prefect.io/contact If you want, I can also help you figure out the minimum role you’d want on Pro for a GitHub Actions deployment service account.

Here’s the practical breakdown. Short version: - The 225 hours applies to Prefect-managed serverless execution time, not worker uptime - It’s essentially based on the lifetime of each serverless flow run on Prefect-managed compute, measured in wall-clock time - Not all Azure-worker workloads are a drop-in fit for Prefect Serverless - The biggest constraints are typically: - 24-hour max runtime - managed runtime / fixed resources - custom image / dependency flexibility depends on serverless mode - You can estimate usage pretty well from your current flow durations Docs: - Serverless / work pool concepts: Work pools - Deploy with serverless / managed execution docs: Serverless execution - Pricing: prefect.io/pricing 1. What counts against the 225 hours? Based on the current docs, the included hours are for managed serverless execution, and usage is tied to compute runtime for flow runs. That means it is not: - worker uptime - idle polling time - your Azure VM/container uptime It is much closer to: - wall-clock runtime of each flow run on Prefect-managed serverless infrastructure Important details from the docs/research: - usage is measured from compute startup through teardown - billed/consumed in minute increments, rounded up to the nearest minute - a run that takes 30 seconds counts as 1 minute - a run that takes 1 minute 5 seconds counts as 2 minutes So if Team includes 225 hours/month, that’s roughly: -

225 * 60 = 13,500 minutes/month

A rough formula:

text
monthly managed serverless usage
≈ sum over all runs of ceil(run wall-clock minutes)

So if you have: - 100 runs/month at 10 min each = ~1,000 min - 500 runs/month at 20 min each = ~10,000 min Total = ~11,000 min = ~183.3 hours 2. Can Prefect Serverless run the same flows as Azure-hosted workers? Sometimes yes, but not always as a 1:1 replacement. There are two important serverless-style models to distinguish: - Managed work pools: - Prefect hosts the execution compute - these are the ones associated with included/consumption-limited hours - Push work pools: - Prefect triggers execution in your cloud provider - these are also serverless operationally, but compute runs in your infra/account For replacing Azure-hosted workers specifically: Managed serverless is a good fit if: - flows are under 24 hours - your dependency setup is straightforward - you don’t need deep infrastructure customization - your resource needs fit the managed environment - you want to reduce or eliminate always-on worker infrastructure Managed serverless may not be a good fit if: - you need custom Docker images - you need OS-level/system package customization - you need special binaries/drivers - you need GPU/specific machine shapes - your runs can exceed 24 hours - you need very strict networking/VNet/private infra controls beyond what managed execution supports Key limitations called out by the docs/research: Managed work pools - fixed resources per run - no arbitrary custom image flexibility like a self-managed worker deployment - package installation is supported, but it’s not the same as full environment control - 24-hour hard limit Push work pools - more flexible than managed - can better align with your cloud-native patterns - still 24-hour limit per run per docs - but compute cost remains in your cloud account, so this may reduce worker overhead without fully eliminating Azure spend Azure-hosted workers / hybrid - most flexible - best if you need: - custom images - long-running jobs - custom networking - special runtimes/dependencies - per-job infra tuning So the honest answer is: - Simple Python/data workflows: often yes, managed serverless can replace Azure workers

- Complex infra-sensitive workloads: maybe not - Long-running or heavily customized workloads: likely better on workers or push pools 3. How do we estimate how many serverless hours we’d use? Yes — the easiest estimate is based on your historical flow run durations. For managed serverless, a good approximation is:

text
estimated monthly serverless minutes
= sum(ceil(each flow run duration in minutes))

Then compare that to:

text
13,500 minutes/month = 225 hours/month

Example:

text
Flow A: 300 runs/month, avg 6.2 min
  => 300 * 7 = 2,100 min

Flow B: 100 runs/month, avg 42 min
  => 100 * 42 = 4,200 min

Flow C: 20 runs/month, avg 185 min
  => 20 * 185 = 3,700 min

Total = 10,000 min/month
      = 166.7 hours/month

That would fit under 225 hours. A second example with shorter frequent runs:

text
1,500 runs/month, avg 35 sec each
=> each run rounds to 1 minute
=> 1,500 min total
=> 25 hours/month

That rounding effect matters a lot for short flows. How to estimate from your current Azure usage Use one of these approaches: Best approach: use Prefect run history - export or inspect historical flow run durations - group by deployment/flow - calculate monthly total of rounded-up runtime minutes - compare that against 13,500 min Decent proxy: Azure compute logs If your current workers execute one flow run per ephemeral container/job: - container/job runtime is a decent approximation If your workers are long-lived and run many jobs: - worker uptime is not useful - you need actual flow run durations, not VM/container uptime Rule of thumb - If your current Azure spend is mostly from always-on workers, managed serverless can reduce that significantly - If your spend is mostly from the jobs themselves and those jobs are long/heavy, managed serverless may not save much and could be constrained by limits Practical decision framework Managed serverless is promising if your flows are mostly: - under 1–2 hours - standard Python dependencies - no custom base image requirements - bursty/intermittent workloads - currently paying for idle worker capacity Stay on Azure workers or consider push pools if your flows need: - custom Docker images - private networking/custom infra - large/specialized compute - >24 hour runs - stricter environment reproducibility My recommendation for your situation Before upgrading specifically for the 225 included hours, I’d do this: 1. Pull a month of historical flow run durations 2. Compute: - average run duration - p95 duration - total monthly rounded-up minutes 3. Flag any deployment with: - runtime near or above 24 hours - custom image/system dependency needs - special Azure/networking assumptions 4. Split workloads into: - good managed-serverless candidates - push-pool candidates - must stay on workers If you want, I can help you build a simple estimator from your Prefect run history — for example, a small script or SQL/CSV calculation that converts historical run durations into estimated monthly serverless-hour consumption.