Description #
Configuration. We all need it. We all hate it. And somehow, we all manage to screw it up at least once in every project.
Over the years, I’ve seen it all – configs manually created for each environment, dumping a bunch of values in a JSON, manually reading env variables without any type consistency, and whole pipelines failing because of a missing comma. But after a decade of suffering, I finally found the way: Pydantic settings.
With Pydantic, we get a configuration that’s:
✅ Type-safe (No more guessing if that “timeout” value is actually an integer!)
✅ Flexible (Works seamlessly across local setups, Docker, Kubernetes, and the cloud)
✅ Easy to validate (Stop your app from crashing at runtime because someone put “True” instead of True)
✅ Perfect for testing (Yes, we’re gonna talk pytest tricks too)
BUT we will not talk about basic Pydantic settings features. We will deep dive into advanced typing to create a super-strict, no-mistakes-guaranteed config that will last longer than any JavaScript framework. Not only that, you will see how to use it in your project without relying on global state, with some practical, battle-tested rules I’ve learned over the years.
By the end of this talk, you’ll walk away knowing:
🎯 Why most traditional config approaches suck
🎯 How to build a rock-solid configuration setup with Pydantic
🎯 How to actually test your configs and their usage properly (so they don’t explode in production)
🎯 Some hidden Pydantic tricks you probably haven’t heard of
If you think configuration is boring, I dare you to sit through this talk and not feel at least a tiny bit excited about it. Worst case? You’ll leave with fewer config-related nightmares. Best case? You’ll finally have a configuration setup that just works.
P.S. These techniques go beyond configuration—you might end up using them for other parts of your project too! 🚀
Example repo #