# svb_config/secret_loader.py import boto3 def load_svb_secrets(): client = boto3.client('secretsmanager') response = client.get_secret_value(SecretId='svb/production/banking') return json.loads(response['SecretString']) For type safety (especially critical in fintech), replace raw dictionaries with Pydantic models:
But what exactly is "SVB config"? While it lacks the immediate recognition of generic terms like .env or settings.py , the SVB configuration pattern represents a critical architecture for managing secrets, environment tiers, and service bindings—particularly in financial technology sectors inspired by institutions like Silicon Valley Bank (SVB).
# svb_config/development.py from .base import * DEBUG = True SECRET_KEY = "dev-key-not-for-prod" ALLOWED_HOSTS = ["localhost", "127.0.0.1"] SVB_API_URL = "http://localhost:8001/mock-svb" Step 4: Dynamic Loading (The Config Dispatcher) The magic of SVB config lies in the __init__.py . It dynamically selects the correct module based on an environment variable. svb config
project/ ├── svb_config/ │ ├── __init__.py │ ├── base.py # Defaults (all environments) │ ├── development.py # Local dev overrides │ ├── staging.py # Staging-specific │ ├── production.py # Production (secrets come from env vars) │ └── validators.py # Custom validation rules ├── .env.template └── manage.py The base.py file contains everything that does not change between environments. Notice how sensitive values are left as placeholders.
class Config: env_file = ".env" validate_assignment = True config = SVBConfig() In a post-SVB-crisis world, many banks require regional failover. An advanced SVB config supports a list of endpoints: # svb_config/secret_loader
Start today. Separate your secrets from your code. Validate at boot. And always have a rollback plan for your config.
# health.py def check_svb_config(): required = ["SVB_CLIENT_ID", "SVB_API_URL"] missing = [r for r in required if not os.environ.get(r)] if missing: raise Exception(f"Missing SVB config: {missing}") Fix: Create a dedicated config.py module that is imported everywhere. Never write os.environ.get() inside a view or service class. Real-World Use Case: Migrating from SVB to a New Bank The most compelling reason to master SVB config is disaster recovery. Imagine your startup uses SVB for payouts. Suddenly, SVB fails. Your new bank (say, Mercury) has a different API structure. It dynamically selects the correct module based on
# svb_config/base.py import os from pathlib import Path BASE_DIR = Path( file ).resolve().parent.parent Security - these MUST be overridden in environment-specific configs SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY", "dev-only-insecure") DEBUG = False # Never default to True in base SVB-specific service bindings - the "B" in SVB SVB_API_URL = os.environ.get("SVB_API_URL", "https://api.svb.com/v1") SVB_CLIENT_ID = os.environ.get("SVB_CLIENT_ID") SVB_CLIENT_SECRET = os.environ.get("SVB_CLIENT_SECRET") Database - note how credentials are absent from hard-coded strings DATABASES = { "default": { "ENGINE": "django.db.backends.postgresql", "NAME": os.environ.get("DB_NAME"), "USER": os.environ.get("DB_USER"), "PASSWORD": os.environ.get("DB_PASSWORD"), "HOST": os.environ.get("DB_HOST"), "PORT": os.environ.get("DB_PORT", "5432"), } } Feature flags (Variables) FEATURE_NEW_ONBOARDING = False FEATURE_BANK_API_V2 = os.environ.get("FEATURE_BANK_API_V2", "False") == "True" Step 3: Environment-Specific Overrides production.py – Strict, no defaults.