Short answer: that DB URL shouldn’t be showing up in a client profile, and you can safely remove it. It’s a server-only setting. If it keeps reappearing, there are a few ways to stop it. Context (Prefect 3.x): -

PREFECT_API_DATABASE_CONNECTION_URL

is only used by the Prefect Server process to connect to its database. Clients/workers just need

PREFECT_API_URL

(and

PREFECT_API_KEY

if Cloud). - Its presence in your

profiles.toml

when you’re just connecting to a remote server is unnecessary. How to prevent it from being written again: 1) Avoid writing to profiles.toml by not using “profile use” - Instead of persisting an “active” profile to disk, pick a profile per command:

prefect -p <profile> <command> ...

or

PREFECT_PROFILE=<profile> prefect <command> ...

This does not modify

profiles.toml

. 2) Remove/unset the setting from the profile - Run:

prefect config unset PREFECT_API_DATABASE_CONNECTION_URL

If you manage multiple profiles, run with a specific profile without persisting:

prefect -p <profile> config unset PREFECT_API_DATABASE_CONNECTION_URL

3) Check environment sources that may be reintroducing it - Make sure it’s not set in your shell,

.env

,

prefect.toml

, or

pyproject.toml

. You can see where a value comes from with:

prefect config view --show-sources

4) If you encounter interactive prompts, disable them - While switching profiles shouldn’t prompt, if you see prompts that lead to write-backs, run with:

prefect --no-prompt profile use <profile>

or set

PREFECT_CLI_PROMPT=false

. Notes and references: - Settings and profiles overview: Settings and profiles (Prefect 3) - Self-hosted server CLI (server-side settings like DB URL): Server CLI guide - Related GitHub issue showing DB URL is server-side and not respected from a client profile: PREFECT_API_DATABASE_CONNECTION_URL ignored from profile If this still repopulates after unsetting and avoiding env sources, ping me with your Prefect version, the exact commands you run, and the output of

prefect config view --show-sources

. It may be a bug we should escalate.