Yes — sort of, but in practice Prefect expects the browser UI and the API to be reachable together. For a Helm-based self-hosted Prefect server: - the UI is usually served at

<https://your-host/>

- the API is usually served at

<https://your-host/api>

The key setting is: -

server.uiConfig.prefectUiApiUrl

This becomes

PREFECT_UI_API_URL

, which tells the browser-based UI where to send API requests. So if your UI is exposed at: -

<https://prefect.example.com>

then you usually want:

yaml
server:
  uiConfig:
    prefectUiApiUrl: "<https://prefect.example.com/api>"

Important: there is not really a fully independent “UI URL” and “API URL” model in the usual self-hosted setup. The normal pattern is one external host, with

/

for UI and

/api

for API. If you point

prefectUiApiUrl

at an Okta URL that does not correctly proxy to Prefect’s

/api

, the UI will fail because all browser API calls go there. So for your Okta integration, the right approach is usually: - put one ingress / external URL in front of Prefect - protect that URL with Okta - make sure: -

https://.../

serves the Prefect UI -

https://.../api

routes to the Prefect API - set:

yaml
  server:
    uiConfig:
      prefectUiApiUrl: "<https://your-okta-protected-host/api>"

If you try to do: - UI at

<https://ui.example.com>

- API at

<https://api.example.com>

that can be difficult because of browser auth/cors/proxy behavior, and it’s not the standard Helm deployment pattern. So the short answer is: - Yes, there are UI-related config values - But the important one is

prefectUiApiUrl

- Recommended setup: one host for both UI and API, with API under

/api

Useful references: - Prefect Helm chart README - Self-hosting docs If you want, paste your current

values.yaml

ingress +

uiConfig

section and I can tell you exactly what to change.

Yes — that’s a reasonable pattern. In practice, if you want: - users to access the Prefect UI through Okta - internal services / agents / workers to talk to the API without going through the browser/Okta flow then you often expose two routes to the same Prefect server: 1. External ingress for humans / UI - protected by Okta - serves UI at

/

- serves API at

/api

- example:

<https://prefect.company.com>

2. Internal ingress or internal service DNS for machine-to-machine API access - not behind interactive Okta login - only reachable inside the cluster/VPC/network - example:

<http://prefect-server.prefect.svc.cluster.local:4200/api>

- or

<https://prefect-api.internal.company.com/api>

The important distinction is: -

server.uiConfig.prefectUiApiUrl

should point to the browser-accessible API URL - workers/agents/automation clients can use a different internal API URL in their own config So for example:

yaml
server:
  uiConfig:
    prefectUiApiUrl: "<https://prefect.company.com/api>"

And then internally you might configure workers with something like:

bash
PREFECT_API_URL=<http://prefect-server.prefect.svc.cluster.local:4200/api>

or your internal ingress URL. So the answer is: - Yes, using one Okta-protected ingress for UI/browser access and another internal-only API endpoint for backend usage is often the cleanest setup. - No, the UI itself should generally not use the internal API URL — it should use the external URL from

prefectUiApiUrl

. A simple mental model: - Browser UI → uses

prefectUiApiUrl

- Workers / scripts / services → use their own

PREFECT_API_URL

If you want, I can sketch a concrete Kubernetes ingress example for: - external Okta-protected UI/API - internal-only API access

Yes — the Helm chart supports that. You can use: -

ingress.host

for the primary hostname -

ingress.extraHosts

for additional hostnames Example:

yaml
ingress:
  enabled: true
  className: nginx

  host:
    hostname: <http://prefect.company.com|prefect.company.com>
    path: /
    pathType: Prefix

  extraHosts:
    - name: <http://prefect-api.internal.company.com|prefect-api.internal.company.com>
      path: /
      pathType: Prefix

And if you're using TLS, also add

extraTls

for the extra hostname(s). Example:

yaml
ingress:
  enabled: true
  className: nginx

  host:
    hostname: <http://prefect.company.com|prefect.company.com>
    path: /
    pathType: Prefix

  tls: true

  extraHosts:
    - name: <http://prefect-api.internal.company.com|prefect-api.internal.company.com>
      path: /
      pathType: Prefix

  extraTls:
    - hosts:
        - <http://prefect-api.internal.company.com|prefect-api.internal.company.com>
      secretName: prefect-api-internal-tls

A couple of important notes: - Both hosts will still point to the same Prefect server service - This is good for your use case if you want: -

<http://prefect.company.com|prefect.company.com>

for Okta-protected human access -

<http://prefect-api.internal.company.com|prefect-api.internal.company.com>

for internal API usage Then set the UI-facing API URL to the external/browser-accessible one:

yaml
server:
  uiConfig:
    prefectUiApiUrl: "<https://prefect.company.com/api>"

And internal workers/services can use:

bash
PREFECT_API_URL=<https://prefect-api.internal.company.com/api>

If you want, I can help you write a full

values.yaml

snippet for: - Okta external ingress - internal API host - correct

prefectUiApiUrl

setting Reference: - Prefect Helm chart README