Hey! Going well — how can I help today? Happy to jump in on anything Prefect-related: deployments, scaling/parallelism, debugging runs, you name it.

Here’s a quick, practical overview of how settings work in Prefect (assuming Prefect 3.x). What settings are and where they come from - Prefect composes settings from multiple sources. Highest → lowest precedence: 1) Programmatic overrides in your code (via context managers) 2) Environment variables (PREFECT_…) 3) .env file in your working directory 4) File secrets (Pydantic feature) 5) prefect.toml (project-local) 6) pyproject.toml under [tool.prefect] (project-local) 7) Active profile (usually at ~/.prefect/profiles.toml) - Environment variables are the easiest way to override values at deploy/run time. Common ways to view and change settings - CLI (verified) - View current settings

prefect config view
    prefect config view --show-defaults

- Set or unset values in the active profile

prefect config set PREFECT_LOG_LEVEL=DEBUG
    prefect config unset PREFECT_LOG_LEVEL

- Validate your profile

prefect config validate

- Manage profiles

prefect profile ls
    prefect profile create my-profile
    prefect profile use my-profile
    prefect profile inspect my-profile

- Use a profile for a single command

prefect --profile my-profile deploy

Profiles - Profiles let you persist named sets of settings (e.g., dev/staging/prod). - Default location: ~/.prefect/profiles.toml (can be changed with PREFECT_PROFILES_PATH or PREFECT_HOME). - Ways to activate a profile (highest → lowest): - CLI flag:

--profile

- Env var:

PREFECT_PROFILE=name

- The “active” key in profiles.toml - Temporarily switch profiles in code:

from prefect.context import use_profile

  with use_profile("staging"):
      ...

Using settings in code - Read settings

from prefect.settings import get_current_settings, PREFECT_API_URL

  s = get_current_settings()
  print(s.api.url)           # structured access
  print(PREFECT_API_URL.value())  # direct by key

- Temporarily override settings (highest precedence while the context is active)

from prefect.settings import temporary_settings, PREFECT_LOG_LEVEL

  with temporary_settings(updates={PREFECT_LOG_LEVEL: "DEBUG"}):
      ...

- Update the active profile programmatically (persists)

from prefect.settings import update_current_profile, PREFECT_API_URL

  update_current_profile({PREFECT_API_URL: "<https://my-api.example.com/api>"})

Project-level config - prefect.toml in your repo (project-local settings):

# flat keys work
  PREFECT_LOG_LEVEL = "INFO"

  # or structured sections
  [api]
  url = "<http://127.0.0.1:4200/api>"

  [logging]
  level = "DEBUG"

- pyproject.toml (same keys under [tool.prefect]):

[tool.prefect]
  PREFECT_LOG_LEVEL = "INFO"

  [tool.prefect.api]
  url = "<http://127.0.0.1:4200/api>"

- .env is also read and sits above project files in precedence. Environment variables - All settings can be expressed as env vars with the

PREFECT_

prefix. Examples: -

PREFECT_API_URL=https://...

-

PREFECT_API_KEY=...

-

PREFECT_LOG_LEVEL=DEBUG

- Nested settings use underscores in env vars, but you’ll usually work with them via the structured objects in code (e.g.,

get_current_settings().logging.level

). Key differences from Prefect 2.x - 3.x uses a more structured, Pydantic-powered settings system. - Profiles and project files (prefect.toml / pyproject.toml) are first-class and merge cleanly with env vars. - The

prefect config

and

prefect profile

commands reflect the 3.x model. If you share what you’re trying to configure (e.g., API URL for Cloud/Server, logging verbosity, task concurrency, deployment behavior), I can give you the exact env vars, CLI, or code snippet to set it up.