Typed config with pydantic-settings

The FastAPI control plane is the single front door to the platform. Every knob it exposes comes from config: database URLs, MinIO keys, Airflow endpoints, Great Expectations paths. pydantic-settings gives us typed option classes so a missing or misnamed env var fails loudly on boot, not during a 3am page.

config/database_options.py
python
from pydantic_settings import BaseSettings, SettingsConfigDict


class DatabaseOptions(BaseSettings):
    model_config = SettingsConfigDict(env_prefix='DB_', env_file='.env', extra='ignore')

    postgres: str = ''
    mysql: str = ''
    command_timeout_seconds: int = 30

A typed option class. env_prefix DB_ means it reads DB_POSTGRES and DB_MYSQL from the environment. The class becomes a first-class dependency in FastAPI routes and services.

Three wins from typed config. One, a typo in an env var name fails on boot with a readable error. Two, values like command_timeout_seconds are ints, not strings, so you never divide by a string in production. Three, defaults are right there next to the type, so the docs for an option class are the class itself.

One options class per concern

Each external dependency gets its own typed class. FastAPI wires them into routes on demand.

Typed option classes separate concerns and fail loudly on bad config.

Yes. Anything a teammate should not see locally. Production DB passwords, third-party API keys, signing secrets. Those come from the cloud provider secret store at runtime. .env is fine for docker-compose dev defaults. The option classes read from either source, so your code never needs to know which.

Fill in the blanks: Add AirflowOptions to the config

Loading practice…

Quiz: Quiz

Loading practice…