Short answer: you can’t. The self-hosted open-source Prefect Server (Prefect 3.x) does not include built-in users, authentication, or RBAC. Anyone who can reach your Server UI/API has full access. Common approaches if you must self-host: - Put the UI/API behind your IdP via a reverse proxy (e.g., OAuth2 Proxy with NGINX/Traefik). This gates access but does not provide per-user roles inside Prefect—everyone who gets through has the same access. - Restrict access at the network layer (VPN, private VPC, IP allowlists). - Run multiple isolated Prefect Server instances (one per team/project) if you need separation without RBAC. If you need true user management and RBAC, use Prefect Cloud, which supports team management, SSO, and granular access controls: - Manage users in Prefect Cloud - Security considerations for Prefect deployments - Access controls and team management overview If you share what level of control you’re looking for (UI auth only, programmatic separation, RBAC, SSO/SCIM, etc.), I can suggest a concrete setup (e.g., an example OAuth2 Proxy + NGINX config) or the right Cloud plan.

Short answers: - Custom domain: Not supported. Prefect Cloud workspaces live under Prefect’s domain; there isn’t a way (on free or paid plans) to bind the UI to your own URL. - Public read-only (unauthenticated): Not supported. All access to Prefect Cloud requires authentication. What you can do: - Invite collaborators with read-only access using the Viewer role. See Manage roles in Prefect Cloud and Manage users and access. - If you need a public-facing status page, build a small proxy app that: - Runs on your domain - Uses a scoped, read-only service token to query Prefect Cloud’s API server-side - Renders selected data to the browser (never expose the token client-side) If you share your exact goal (e.g., embedding a run dashboard on your site vs. sharing a status page with customers), I can outline a concrete approach and example.

Got it — since you’re self-hosting OSS, it’s on your domain. There isn’t a built-in “view-only” mode in Prefect Server, so anyone who can reach the UI/API can trigger runs. However, you can effectively make the UI read-only by blocking the API endpoints that create/modify runs at your reverse proxy. Key endpoints to block (these power the “Run” buttons, manual restarts, etc.): - Create run from a deployment: - POST /api/deployments/{deployment_id}/create_flow_run - Docs: Create flow run from deployment - Create a flow run directly: - POST /api/flow_runs - Docs: Create flow run - Change a flow run’s state (e.g., retry/resume from UI): - POST /api/flow_runs/{flow_run_id}/set_state - Docs: Set flow run state Recommended approaches - Reverse-proxy deny rules (public read-only): - Allow GET/OPTIONS to the API but deny POST to the endpoints above. - Example NGINX snippet (public UI route):

# Public read-only route
    server {
      server_name <http://ui.example.com|ui.example.com>;

      # Allow GET/OPTIONS generally
      location /api/ {
        if ($request_method !~ ^(GET|OPTIONS)$) { return 403; }
        proxy_pass <http://prefect-server>;
      }

      # Explicitly block known trigger endpoints (defense-in-depth)
      location ~* ^/api/deployments/.+/create_flow_run$ { return 403; }
      location = /api/flow_runs { if ($request_method != GET) { return 403; } }
      location ~* ^/api/flow_runs/.+/set_state$ { return 403; }

      location / { proxy_pass <http://prefect-server>; }
    }

- Keep workers functional: - Workers need to POST to various endpoints (claim work, update states, send logs, etc.). Give them a separate “private” route that allows POSTs, restricted by IP/VPN:

# Private route for workers/CLI
    server {
      server_name <http://api.internal.example.com|api.internal.example.com>;

      allow 10.0.0.0/8;  # your worker CIDR(s)
      deny all;

      location / { proxy_pass <http://prefect-server>; }
    }

- Point your workers/CLI to the private route; point human users to the public read-only route. - With an auth proxy (optional, nicer UX): - Put OAuth2 Proxy (or Traefik ForwardAuth) in front of the API. - Allow GET for everyone. - Require an authorized group (e.g., “prefect-writers”) for POST to the trigger endpoints above. This keeps the UI working for viewers, while only authorized users can trigger runs. Caveats - The UI “Run” buttons will still appear for viewers, but requests will fail with 403 (that’s expected). - Blocking POST globally will break workers; ensure your workers have an allowed path/host. - There’s no server-side toggle to disable manual runs per deployment in OSS. If you can share: - Which proxy you’re using (NGINX, Traefik, Caddy)? - Do your workers reach the same URL as humans, or can they use a private hostname/network? I can tailor exact rules/middleware for your setup.

Short answer: no. Prefect Server (OSS) has no built-in auth or “simple password” mode. The app assumes you’ll secure it with network controls or an auth proxy. Practical options without adding a reverse proxy: - Restrict network access: - Bind Prefect to localhost and use an SSH tunnel when you need access:

ssh -L 4200:localhost:4200 user@your-server
    # then open <http://localhost:4200> (adjust port if needed)

- Lock down ingress with firewall/security groups (allow only specific IPs). - Put it on a private network/VPN (WireGuard/Tailscale) and require VPN login. If you specifically want an HTTP password prompt, you’ll need to place an auth layer in front (e.g., basic auth via NGINX/Caddy/Traefik or a zero-trust service like Cloudflare Access) since Prefect itself doesn’t provide it. Reference: Security considerations for Prefect deployments If you share your current hosting setup (port, how users reach it), I can suggest the simplest lock-down route for that environment.