Short answer: I’m not aware of a single official “systems requirements / sizing guide” doc from Prefect that gives hard CPU/RAM/disk specs for on-prem hardware, especially for a Prefect Cloud + workers setup. For your target architecture, that’s mostly because Prefect Cloud itself is hosted by Prefect, and your on-prem footprint is usually just: - one or more workers - optional local Docker/host infrastructure those workers submit into - your own observability/logging/secrets/networking stack So the requirements depend much more on your flow workloads than on Prefect control-plane overhead. What Prefect does document - Prefect Cloud: Prefect Cloud concepts - Workers: Workers - Work pools: Work pools - Deployments / `prefect deploy`: Deployment/infrastructure concepts and Work pools for deployments - Run flows in Docker / worker-based execution: Deploy flows with Prefect What this means for your hardware planning Since you’re retiring the legacy OSS server, you do not need to size for: - Prefect API server - Prefect UI server - OSS database - background services/schedulers for self-hosted Prefect You mainly need to size for: 1. Worker process overhead 2. Docker image pulls/builds 3. Concurrent flow runs 4. Your flows’ CPU / RAM / temp disk needs 5. Git clone / code fetch / artifact/log transfer For a few hundred daily runs with “docker-git”-style execution and only tens of GB/day moved, Prefect’s own overhead is usually modest. In practice, the server sizing question is really: How many runs execute concurrently, and how heavy is each containerized flow run? General best-practice guidance I’d give 1) Linux over Windows For self-managed workers, Linux is the usual and recommended choice operationally, especially if you are using Docker-based execution. It tends to be the best-supported and simplest path in the Prefect ecosystem. Windows can work for some local/worker use cases, but for Docker workers on-prem, I would strongly favor Ubuntu or another common Linux distro unless you have a hard Windows requirement. 2) Virtual machines are fine Prefect workers are just long-running processes polling Prefect Cloud and submitting work. They generally run well on: - VMware - Hyper-V - Proxmox - cloud VMs - bare metal Prefect does not, as far as I can tell, publish a specific “supported virtualization platforms” matrix for workers. In practice, if the VM can reliably run: - Python - the Prefect worker - Docker engine - outbound HTTPS to Prefect Cloud then it is usually sufficient. 3) Separate “worker host sizing” from “job sizing” A common mistake is trying to size the worker host based only on number of deployments. What matters more is: - maximum concurrent runs - per-run CPU/memory - image size and pull frequency - temporary working directory usage - whether runs share the same Docker host If your worker host is also the Docker execution host, then that machine needs enough capacity for all concurrently running containers plus some headroom. 4) Start with conservative VM sizing if workloads are modest For a modest/shared worker host, a reasonable starting point is often something like: - 4–8 vCPU - 16–32 GB RAM - 100–200 GB fast SSD Then increase based on: - observed concurrent container count - memory pressure - image cache size - logs/artifacts/temp storage - peak run duration overlap If your flows are light ETL / API / file-transfer jobs, that may be enough. If they do heavier transforms, pandas joins, db extracts, or multiple parallel containers, you may need substantially more.

5) Prefer multiple smaller workers over one giant host For resilience and maintenance, it’s often better to use: - multiple worker processes/hosts - separate work pools for different workload classes - tags / queueing / concurrency controls That gives you cleaner isolation than one large all-purpose box. 6) Account for Docker storage and image churn For Docker-based execution, disk sizing is often driven more by: - image layers - cloned repos - temporary run files - logs than by Prefect itself. If you rebuild/pull frequently, watch

/var/lib/docker

growth and ensure log rotation / cleanup. 7) Network requirements matter more than people expect Your workers need reliable outbound access to: - Prefect Cloud - your Git provider - container registries - destination data systems In many environments, proxy/firewall/TLS constraints are a bigger deployment issue than CPU/RAM. If you need an answer for your infrastructure team, I’d phrase it like this “Because we are moving to Prefect Cloud, there is no longer a need to host Prefect’s API, UI, or database on-prem. The on-prem requirement is only for worker/execution infrastructure. Prefect does not appear to publish fixed hardware sizing guidance for Cloud workers, because sizing depends on the resource profile and concurrency of our flow runs. Prefect workers are lightweight; the main sizing driver is the Docker containers they launch. Linux (Ubuntu) is the preferred platform, and standard VM platforms are acceptable so long as they support Docker, Python, persistent storage, and outbound HTTPS connectivity.” Suggested baseline recommendation for your use case Based on what you described, I’d probably propose as an initial target: - OS: Ubuntu LTS - Platform: standard VM or physical server - CPU: 8 vCPU to start - Memory: 32 GB RAM - Disk: 200 GB SSD minimum - Docker: local engine with cleanup/log rotation - Scaling approach: add another worker host rather than vertically scaling first And if HA/reliability matters: - 2 smaller Linux VMs instead of 1 large server - each running a worker - same or separate work pools depending on isolation needs That said, if your flows are very lightweight, you could likely run smaller. If they are bursty with high concurrency, you may need more. About best-practices docs I did not find an official Prefect doc that serves as a complete “system requirements / hardware recommendations” guide for all deployment types. The most relevant official docs are the worker/work-pool/deployment docs: - Workers - Work pools - Deploy flows with Prefect - Prefect Cloud If you want, I can also help you turn your current workload into a more concrete sizing recommendation for IT — e.g. “given X concurrent runs, Y average container memory, Z image sizes, recommend N worker hosts with these specs.”

Yes — the fastest way is to measure concurrency, per-run resource usage, and Docker storage/network behavior on your current host(s), then size the replacement from those numbers. I’d collect data in 5 buckets: 1. Prefect workload shape You want: - runs/day - peak concurrent runs - average + p95 run duration - which flows are “heavy” - how bursty schedules are by hour 2. Container resource usage You want: - CPU used per running container - memory used per running container - p95 / max memory for your heaviest jobs - whether jobs are mostly CPU-bound, memory-bound, or I/O-bound 3. Host-level pressure You want: - host CPU saturation - memory pressure / swapping - disk utilization - disk IOPS / wait - network throughput - Docker storage growth 4. Image/code-fetch behavior You want: - image sizes - pull frequency - git clone size/frequency - whether jobs reuse cached images or constantly re-pull 5. Operational headroom You want: - how much spare capacity you need during bursts - whether you need one larger host or two smaller worker hosts A practical approach is: Run measurements for at least 1 normal business week, ideally including your busiest day. --- What to extract from Prefect first From Prefect Cloud / your existing deployments, try to estimate: - total runs/day by deployment - average runtime by deployment - busiest hour of the day - max number of runs active at once - number of runs typically queued at once If you already know some deployments are “large memory” or “large transfer” jobs, group them separately. A simple worksheet for each deployment: - deployment name - runs/day - avg runtime - p95 runtime - estimated memory per run - estimated CPU per run - estimated temp disk use - image used - code repo used Then compute rough concurrency:

concurrency ≈ runs_per_day × avg_runtime_hours / 24

That gives average concurrency. For sizing, you care more about peak concurrency, so use schedule overlap and actual observed peaks. Example: - 240 runs/day - avg runtime 20 min = 0.333 hr Average concurrency:

240 × 0.333 / 24 = 3.33

But if many runs happen in the same 2–3 hour window, peak concurrency could easily be 8–15 instead of 3. --- What to collect from the Ubuntu server If your flows run in Docker containers on that host, these are the most useful Linux-level checks. 1) CPU / memory / load over time Install a lightweight monitoring stack if you don’t already have one: -

sysstat

(

sar

) -

atop

-

htop

- optional: Prometheus + node_exporter + cAdvisor if you want nicer history Useful commands:

sudo apt-get update
sudo apt-get install -y sysstat htop atop

Enable

sysstat

if needed, then collect: - CPU utilization - run queue / load - memory used/free - swap activity Examples:

sar -u 1 10
sar -r 1 10
sar -q 1 10
sar -S 1 10

What to look for: - sustained CPU > 70–80% during peaks - swap usage or non-zero swap in/out - load average much higher than vCPU count - memory available getting very low If any of those happen now, that’s a sign your current host may already be under-sized. --- 2) Disk usage and I/O For Docker workloads, disk is often overlooked. Check: - total filesystem usage - Docker data dir usage - disk latency / utilization - temp working dirs Commands:

df -h
du -sh /var/lib/docker
docker system df
iostat -xz 1 10

If

iostat

is not installed:

sudo apt-get install -y sysstat

What to look for: -

%util

near 100% on busy disks - high

await

values -

/var/lib/docker

growing quickly - image cache consuming most disk - temp directories filling up For your use case, SSD is strongly preferred. --- 3) Network throughput Since you mentioned tens of GB/day moved, network probably isn’t huge, but you still want to observe peaks. Commands:

sar -n DEV 1 10
ip -s link

If you want a quick live view:

sudo apt-get install -y iftop nload

Look for: - bursts during image pulls - repo clones

- data transfers to source/destination systems If transfers are only tens of GB/day, this usually won’t be the main sizing constraint unless they’re compressed into narrow windows. --- 4) Docker container usage This is probably the single most important operational signal. Live view:

docker stats --no-stream

Better: sample it periodically during a busy window:

while true; do
  date
  docker stats --no-stream
  sleep 60
done | tee docker-stats.log

What to capture: - number of containers running simultaneously - memory used per container - CPU % per container - which containers are consistently the biggest If container names are ephemeral, correlate them to deployment names if possible via labels or naming conventions. Also inspect images:

docker images
docker system df -v

This tells you: - image sizes - layer reuse - whether repeated pulls are expensive --- 5) Historical container metrics If you don’t already have metrics, consider adding one of these for a week: - cAdvisor - Netdata - Prometheus + Grafana - Datadog / New Relic / your existing infra monitoring For Docker-heavy Prefect environments, cAdvisor + node_exporter is a very practical combo because it gives: - per-container CPU - per-container memory - filesystem usage - network usage - host metrics If you already have VMware/Hyper-V host metrics, those can help too, but guest OS/container metrics are better. --- The most useful “concrete numbers” to bring back to IT Try to produce these 10 values: 1. Peak concurrent Prefect flow containers 2. Average concurrent containers 3. Typical CPU per container 4. Peak CPU per heavy container 5. Typical memory per container 6. Peak memory per heavy container 7. Total host memory used at peak 8. Docker storage currently in use 9. Daily image pull / repo clone behavior 10. Peak network throughput during busiest hour With those, you can make a much stronger recommendation. --- How to turn those into hardware sizing A good first-pass formula: CPU

required_vcpu ≈ sum(peak_cpu_per_concurrent_container) × headroom

Use headroom of about

1.3

to

1.5

. Memory

required_ram ≈ sum(peak_memory_per_concurrent_container) + OS/docker overhead + headroom

For Linux + Docker + worker overhead, I’d reserve at least: - 2–4 GB for OS/platform overhead on a small host - more if you run monitoring/security agents Then add 20–30% memory headroom. Disk

required_disk ≈ docker_images + temp_run_space + logs + growth_headroom

For Docker-based execution, don’t size only to current usage; allow room for: - multiple images - old layers before cleanup - temp files from active runs - log retention --- Example sizing workflow Suppose you observe: - peak concurrent containers: 8 - typical memory: 1.5 GB/container - 2 heavy jobs peak at 4 GB each - typical CPU: ~0.5–1 vCPU/container - peak total active CPU during busy hour: ~6 vCPU - Docker storage: 55 GB - temp usage during peaks: 20 GB Then I’d estimate: Memory - 6 normal containers × 1.5 GB = 9 GB - 2 heavy containers × 4 GB = 8 GB - subtotal = 17 GB - add OS/Docker/monitoring = 4 GB - subtotal = 21 GB - add headroom = ~27 GB => recommend 32 GB RAM CPU - observed peak around 6 vCPU - add headroom 1.5x => recommend 8–12 vCPU Disk - 55 GB Docker - 20 GB temp - OS/logs/working space/headroom => recommend 150–200 GB SSD minimum That’s the kind of defensible recommendation infra teams like. --- If you want a quick-and-dirty data collection checklist, use this During a representative busy period, run:

date
uptime
nproc
free -h
df -h
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
docker stats --no-stream
docker system df
sar -u 1 5
sar -r 1 5
sar -n DEV 1 5
iostat -xz 1 5

And save the output. You can also repeat that every 5–15 minutes during your busiest few hours. --- Best practice: identify your heaviest 3 deployments

For those specifically, find: - max runtime - max memory - whether they overlap - whether they use especially large images - whether they create large temp files Those “top 3 worst-case jobs” often dominate sizing more than the total number of daily runs. --- If you want a more automated approach If you’re comfortable with a bit of scripting, I can help you build either: 1. a simple Bash collection script for your Ubuntu host, or 2. a small Python script that summarizes: - current Docker image sizes - running container stats - host CPU/memory/disk - a CSV you can send to IT If you want, I can draft a copy-pasteable Ubuntu data collection script next.