Prefect provides a number of settings that help secure a self-hosted Prefect server.

​
Basic Authentication

Self-hosted Prefect servers can be equipped with Basic Authentication through two settings:
  • server.api.auth_string="admin:pass": this setting should be set with an administrator / password combination, separated by a colon, on any process that hosts the Prefect webserver (for example prefect server start).
  • api.auth_string="admin:pass": this setting should be set with the same administrator / password combination as the server on any client process that needs to communicate with the Prefect API (for example, any process that runs a workflow).
With these settings, the UI will prompt for the full authentication string "admin:pass" (no quotes) upon first load. It is recommended to store this information in a secure way, such as a Kubernetes Secret or in a private .env file.
Note on API keysAPI keys are only used for authenticating with Prefect Cloud.If both PREFECT_API_KEY and PREFECT_API_AUTH_STRING are set on the client, PREFECT_API_KEY will take precedence. If you plan to use a self-hosted Prefect server, make sure PREFECT_API_KEY is not set in your active profile or as an environment variable, otherwise authentication will fail (HTTP 401 Unauthorized).
Example .env file:
.env
PREFECT_SERVER_API_AUTH_STRING="admin:pass"
PREFECT_API_AUTH_STRING="admin:pass"

​
Host the UI behind a reverse proxy

When using a reverse proxy (such as Nginx or Traefik) to proxy traffic to a hosted Prefect UI instance, you must also configure the self-hosted Prefect server instance to connect to the API. The ui.api_url setting should be set to the external proxy URL. For example, if your external URL is https://prefect-server.example.com then you can configure a prefect.toml file for your server like this:
prefect.toml
[ui]
api_url = "https://prefect-server.example.com/api"
If you do not set ui.api_url, then api.url will be used as a fallback.

​
CSRF protection settings

If using self-hosted Prefect server, you can configure CSRF protection settings.
  • server.api.csrf_protection_enabled: activates CSRF protection on the server, requiring valid CSRF tokens for applicable requests. Recommended for production to prevent CSRF attacks. Defaults to False.
  • server.api.csrf_token_expiration: sets the expiration duration for server-issued CSRF tokens, influencing how often tokens need to be refreshed. The default is 1 hour.
  • client.csrf_support_enabled: enables or disables CSRF token handling in the Prefect client. When enabled, the client manages CSRF tokens for state-changing API requests. Defaults to True.
By default clients expect that CSRF protection is enabled on the server. If you are running a server without CSRF protection, you can disable CSRF support in the client.

​
CORS settings

If using self-hosted Prefect server, you can configure CORS settings to control which origins are allowed to make cross-origin requests to your server.

​
Custom client headers

The client.custom_headers setting allows you to configure custom HTTP headers that are included with every API request. This is particularly useful for authentication with proxies, CDNs, or security services that protect your Prefect server. 
export PREFECT_CLIENT_CUSTOM_HEADERS='{
  "Proxy-Authorization": "Bearer your-proxy-token",
  "X-Corporate-ID": "your-corp-identifier"
}'
Certain headers are protected and cannot be overridden for security reasons:
  • User-Agent: Managed by Prefect to identify client version and capabilities
  • Prefect-Csrf-Token: Used for CSRF protection when enabled
  • Prefect-Csrf-Client: Used for CSRF client identification
If you attempt to override these protected headers, Prefect will log a warning and ignore the custom value to maintain security.
Store credentials securelyWhen using custom headers for authentication, ensure that sensitive values like API keys and tokens are stored securely using environment variables, secrets management systems, or encrypted configuration files. Avoid hardcoding credentials in your source code.