Short answer: - The reverse proxy isn’t strictly required, but it’s very useful for a production/self‑hosted Prefect server. - Yes—Prefect’s UI uses a real‑time channel (WebSockets/streaming) for live updates (e.g., logs and run state changes), so your proxy must allow upgrade connections. Why put Nginx (or similar) in front of Prefect? - TLS termination and HTTP→HTTPS redirect - Stable public domain/DNS and path routing (serve multiple services on one host) - Forward/normalize headers (Host, X‑Forwarded‑Proto, Authorization) - Add security controls (rate limits, IP allowlists, HSTS) and request/response tuning - Optional buffering/timeout tweaks for streaming/logs and long‑lived connections - Centralized access/error logs WebSockets/streaming - The Prefect UI opens upgraded, long‑lived connections to the API for live data. If the proxy doesn’t pass Upgrade/Connection headers (and keep the connection open), you’ll see stale or missing live updates in the UI. - Workers generally talk to the API over normal HTTP; the live channel is primarily for the UI. Your config looks close. A few small additions make it more robust: - Ensure HTTP/1.1 to upstream for WebSockets - Pass X‑Forwarded‑Proto - Consider longer timeouts and disable buffering for streaming - Use a safe Connection header mapping so non‑WS requests don’t get “upgrade” Example Nginx snippet you can adapt:

upstream prefect_api {
    server 127.0.0.1:4200;  # or wherever your Prefect API listens
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    server_name <http://prefect.example.com|prefect.example.com>;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name <http://prefect.example.com|prefect.example.com>;

    ssl_certificate /path/to/ssl/certificate.pem;
    ssl_certificate_key /path/to/ssl/certificate_key.pem;

    # Optional: increase if you upload larger payloads
    client_max_body_size 50m;

    location /api {
        proxy_http_version 1.1;                 # important for WebSockets
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;

        # WebSocket + streaming support
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_buffering off;

        # Auth header passthrough
        proxy_set_header Authorization $http_authorization;
        proxy_pass_header Authorization;

        proxy_pass <http://prefect_api>;
    }

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;

        proxy_pass <http://prefect_api>;
    }
}

More background - Prefect server overview: Prefect 3 Server concepts - Example of running Prefect behind a reverse proxy (community example): Docker Compose with reverse proxy If you’re planning to host Prefect under a subpath (e.g., https://example.com/prefect/), call that out—there are a couple of extra settings we should review for base URLs.