How to secure a self-hosted Prefect server
Learn about the Prefect settings that add security to your self-hosted server.
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 exampleprefect 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 keys
API 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:
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:
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 toFalse
.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 toTrue
.
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.
server.api.cors_allowed_origins
: a list of origins that are allowed to make cross-origin requests.server.api.cors_allowed_methods
: a list of HTTP methods that are allowed to be used during cross-origin requests.server.api.cors_allowed_headers
: a list of headers that are allowed to be used during cross-origin requests.
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.
Certain headers are protected and cannot be overridden for security reasons:
User-Agent
: Managed by Prefect to identify client version and capabilitiesPrefect-Csrf-Token
: Used for CSRF protection when enabledPrefect-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 securely
When 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.