Great question. In Prefect 3.x, you can scale the self-hosted API (Prefect Server) in a few complementary ways. Here’s the short guide: - Horizontally scale API webservers - Run multiple stateless API instances and put them behind a load balancer. All instances must share the same PostgreSQL and Redis. - Command per webserver:

prefect server start --host 0.0.0.0 --port 4200 --no-services

- Health check for your LB:

GET /api/health

returns 200 when healthy - Notes: - Use PostgreSQL (not SQLite) for any multi-instance setup - Use Redis for messaging/coordination (see env vars below) - Docs: Scale self-hosted | Server concepts | Health endpoint - Multi-process on a single node (scale up) - Start the API with multiple worker processes:

prefect server start --workers 4

- When

--workers > 1

, background services are disabled automatically (equivalent to

--no-services

) and you must run them separately (next bullet). - Requires PostgreSQL + Redis. - Run background services separately (1 per cluster) - Start the scheduler, automation triggers, event processing, etc. in a single dedicated process:

prefect server services start

- Best practice:

prefect server database upgrade -y    # run once before rollout
    export PREFECT_API_DATABASE_MIGRATE_ON_START=false

- For HA coordination of services, set a Docket URL backed by Redis:

export PREFECT_SERVER_DOCKET_URL="<redis://redis-host:6379/0>"

- Database scaling (PostgreSQL only) - Use PostgreSQL 14.9+ and size connection pools appropriately. Key env vars:

# Connection URL
    PREFECT_API_DATABASE_CONNECTION_URL=<postgresql+asyncpg://user:pass@host:5432/prefect>

    # SQLAlchemy pool sizing
    PREFECT_SERVER_DATABASE_SQLALCHEMY_POOL_SIZE=20
    PREFECT_SERVER_DATABASE_SQLALCHEMY_MAX_OVERFLOW=20
    PREFECT_SERVER_DATABASE_SQLALCHEMY_POOL_TIMEOUT=60
    PREFECT_SERVER_DATABASE_SQLALCHEMY_POOL_RECYCLE=3600

- Optionally place PgBouncer in front of Postgres for high concurrency. - Tune event retention to control DB growth:

PREFECT_EVENTS_RETENTION_PERIOD="2d"

- Settings ref: Settings reference - Redis for messaging and coordination - Select Redis-backed implementations:

PREFECT_MESSAGING_BROKER=prefect_redis.messaging
    PREFECT_MESSAGING_CACHE=prefect_redis.messaging
    PREFECT_SERVER_EVENTS_CAUSAL_ORDERING=prefect_redis.ordering
    PREFECT_SERVER_CONCURRENCY_LEASE_STORAGE=prefect_redis.lease_storage

- Redis connection options (auth/TLS as needed):

PREFECT_REDIS_MESSAGING_HOST=redis-host
    PREFECT_REDIS_MESSAGING_PORT=6379
    PREFECT_REDIS_MESSAGING_DB=0
    PREFECT_REDIS_MESSAGING_USERNAME=...
    PREFECT_REDIS_MESSAGING_PASSWORD=...
    PREFECT_REDIS_MESSAGING_SSL=true

- Guide: Scale self-hosted - Kubernetes with Helm (recommended for production) - Use official charts; scale API via replicaCount and configure Postgres/Redis:

helm repo add prefect <https://prefecthq.github.io/prefect-helm>
    helm install prefect-server prefect/prefect-server -n prefect

- Charts and docs: - Chart repo: Prefect Helm repo - Server chart: prefect-server chart - Worker chart: prefect-worker chart - How-to: Server on Helm - Load balancer and proxy notes

- Put API instances behind an LB/reverse proxy; route to

/api

, health check

/api/health

. - Sticky sessions are not required; API is stateless. - Scale workers separately (execution throughput) - Workers don’t scale the API; they scale your run throughput. Run more workers or increase worker concurrency per work pool:

prefect worker start --pool my-pool --concurrency 10

- Consider Prefect Cloud (managed API) - If you prefer not to run/scale DB + Redis + API yourself, Cloud manages the control plane (HA, upgrades, backups, etc.) for you. You just run workers and your code. - Docs: Prefect 3.x docs Quick checklist to go beyond a single node: - Use PostgreSQL (not SQLite) - Add Redis and set the messaging/ordering/lease env vars - Run N API replicas with

--no-services

behind a load balancer - Run

prefect server services start

once for background services - Tune DB pools and event retention - Use Helm on Kubernetes for repeatable deployments Would you like a tailored plan for your environment? If you can share: - Where you’re running (Kubernetes, VMs, Docker Compose) - Expected flow runs/day and peak concurrency - Current bottleneck (API latency, DB load, worker polling) …I can recommend concrete values, Helm overrides, and topology.