Building a Python Template That Actually Works in Production

I’ve been writing Python for years. And every new project, it’s the same thing—configure logging, set up tests, handle configuration files, wrestle with packaging. Over and over.

Worse, I kept hitting the same security issues across projects. API keys in logs. Secrets in config files. The kind of mistakes that don’t bite you until they really bite you.

So I built a Cookiecutter template. It handles the tedious parts and bakes in the patterns I’ve learned from shipping production code.

The Problem

Most Python templates give you a directory structure. Maybe some tests. That’s fine for experiments, but real applications need more:

• Security: How do you keep sensitive data out of logs? How do you manage secrets across environments?
• Configuration: How do you handle settings in dev vs staging vs production?
• Quality: How do you enforce standards without constant vigilance?
• CI/CD: How do you automate releases without reinventing the wheel?

These aren’t theoretical problems. They’re the issues that show up when your side project starts handling real data.

What I Built

The template solves problems I’ve actually encountered.

Security-Conscious Logging

One of the biggest risks in Python applications—accidentally logging sensitive data. The template includes a logging system that filters out passwords, tokens, and secrets automatically:

# This gets automatically filtered in logs
logger.info(f"User login attempt", extra={
    "user": "retr0", 
    "password": "secret123"  # This won't appear in logs
})

Thread-safe. Structured output. Works in development and production.

Hierarchical Configuration

Real applications need configuration that adapts to context. The template provides a clear precedence:

1. Environment variables (highest priority)
2. Configuration files (YAML/JSON)
3. Sensible defaults (fallback)

You can have a config.yaml for development, override values with environment variables in production, and always fall back to safe defaults. No surprises.

Project Archetypes

The template supports different project types:

• Library: Clean package structure for reusable code
• CLI Application: Rich command-line interface with completion
• Web API: Foundation for web services
• Data Science: Notebook-friendly structure with data handling patterns

Each type gets appropriate tooling.

The Philosophy

I built this around practical needs, not theoretical best practices. Features got added when I actually needed them across multiple projects.

The logging filtering? That came from debugging a production issue where API keys were showing up in log files. The configuration hierarchy? That emerged from managing the same application across dev, staging, and production.

If a pattern keeps proving useful, it belongs in the template. If it doesn’t, it doesn’t matter how elegant it sounds.

What You Get

When you run the template:

• Modern Python packaging (pyproject.toml with proper metadata)
• Code quality tools (Ruff for linting and formatting)
• Security scanning (pre-commit hooks and dependency checks)
• Comprehensive testing (pytest with 90%+ coverage requirements)
• CI/CD pipelines (GitHub Actions with multi-version testing)
• Documentation (MkDocs setup with automatic API docs)

Getting Started

pip install cookiecutter
cookiecutter https://github.com/retr0crypticghost/python-template.git

Answer a few questions. Get a working project with professional patterns built in.

Human + AI

I should mention—I built this collaboratively. I handled the architecture decisions and requirements based on experience. AI helped with implementation details, edge cases, and consistency across generated files.

The result is more thorough than what I could have built alone. But it’s grounded in real problems, not theoretical ideals.

Open Source

The template is open source and evolves based on actual project needs. If you’re building Python applications and want to skip the setup work while getting security and quality practices built in, give it a try.

I’m interested in how people use it and what patterns would be helpful to include. The goal is practical—making it easier to build Python applications that work in production.