@Marvin waht is the best option for self hosted prfect server to split between dev and prod?

✅ thought for 315.1 seconds

how do you mean

split between dev and prod?

Great question. Short answer: run separate Prefect Server instances for dev and prod. Key points: - Prefect Server (self‑hosted) does not support workspaces or multi‑tenancy; that’s a Cloud-only feature. For real isolation, the best practice is independent stacks per environment. - Each environment should have its own Postgres DB and Redis, deployed as: - Kubernetes: separate Helm releases in separate namespaces (e.g., prefect-dev, prefect-prod) - Docker: separate docker-compose projects or hosts/ports - Use Prefect profiles to point your CLI and CI/CD to the right API URL, and create distinct work pools in each environment. Point workers to the matching pool. Typical setup - Infra: - Dev: Server + Services + Postgres + Redis - Prod: Server + Services + Postgres + Redis - Routing: - Work pools: dev-pool and prod-pool in their respective servers - Workers: each worker polls only its env’s pool - Developer/CI switching with profiles:

prefect profile create dev
  prefect profile use dev
  prefect config set PREFECT_API_URL=<https://prefect-dev.internal/api>

  prefect profile create prod
  prefect profile use prod
  prefect config set PREFECT_API_URL=<https://prefect-prod.internal/api>

  # Check settings
  prefect config view

Notes - You can add tags like

env:dev

or

env:prod

for filtering and concurrency policies, but they are not isolation—separate servers are. - For HA/multi-instance servers, ensure Postgres (not SQLite) and Redis are configured; run DB migrations once per environment before scaling API replicas. Helpful docs - Self-hosted scaling and HA: Scaling self-hosted Server - Docker Compose example: Server with Docker Compose - Helm chart (Kubernetes): Server Helm deployment - Settings and profiles (e.g., PREFECT_API_URL): Manage settings & profiles Want me to share a minimal docker-compose pair (dev/prod) or a Helm values.yaml example depending on where you’re deploying? Are you on Kubernetes or Docker today?

Honestly I am doubting what I want, our biggest problem is that right now we have dev and prod on the same infra, it works great but it makes the UI a bit cluttered and harder to figure out what is dev and what is prod. We do have separate docker deployments for dev and prod. If I can easily isolate the UI only that would be fairly decent with lowest amount of effort possible. Different servers is also an option but preferably I want to avoid maintaining both

gotcha, if you wanna stick with one server / UI then i'd just use tags and/or templated names

some-flow/dev-deployment

vs

some-flow/prd-deployment

ye that is what I have now

or if there are specific ways in which the UI is letting you down and making things cluttered, we could open issues about that

The problem arrised today when we had a dev pipeline taking concurrency slot from the prod environment, I guess an option is to have all tags have dev/prod prefix to avoid this

yea that'd be my recommendation if not server isolation

Cool thanks nate!