Live data from Hacker News

Show HN: Django Keel – 10 Years of Django Best Practices in One Template

github.com

1–10 of 32 posts

Show HN: Django Keel – 10 Years of Django Best Practices in One Template

#1
After a decade of shipping Django to production, I got tired of solving the same setup problems on every new project.

Environment-first settings. Sensible auth defaults. Structured logging. CI from day zero. Pre-commit hooks. Docker. Security hardening. Every project meant two days of boilerplate before writing business logic.

So I built Django Keel: a production-ready Django starter that eliminates the yak-shaving. GitHub: https://github.com/CuriousLearner/django-keel

*What you get*:

- 12-factor config with environment-based secrets - Production-hardened security defaults - Pre-wired linting, formatting, testing, pre-commit hooks - CI workflow ready to go - Clear project structure that scales - Documentation with real trade-offs explained

*Background*:

I maintained a popular cookiecutter template for years. Django Keel is what that should've been from the start—battle-tested patterns without the accumulated cruft.

*Who it's for*:

Teams and solo builders shipping Django to production who want a strong baseline without tech debt. Feedback welcome on what works, what doesn't, and what's missing. Issues and PRs appreciated.

Show HN: Django Keel – 10 Years of Django Best Practices in One Template
github.com

Re: Show HN: Django Keel – 10 Years of Django Best Practices in One Template

#2
This looks great - I have one concern with tools like this - what is the update flow when the template is updated?

This is a thing I've been struggling with - what is the best way of delivering such templates. Is a template generator such as this? Would it be best to copy a baseline repo with all options set? Should we fork that base repo and rebase when the baseline updates?

Re: Show HN: Django Keel – 10 Years of Django Best Practices in One Template

#3
post #2

This looks great - I have one concern with tools like this - what is the update flow when the template is updated? This is a thing I've been struggling with - what is the best way of delivering such templates. Is a template generator such as this? Would it be best to copy a baseline repo with all options set? Should we fork that base repo and rebase when the baseline updates?

Great question because this has haunted me for over 10 years with cookiecutter. Most of the time I was copy-pasting newer features from running projects back into the template, and then copy-pasting in other running projects.

But Keel is based on copier which has a "pull" based approach. It means unlike cookiecutter where you generate project from template once, you can run `copier update` to update your project with the latest addition to the template. (It takes care of merging based on the initial config that you selected).

It's just running one command `copier update`. Docs here: https://django-keel.readthedocs.io/en/latest/?h=copier+updat...

You don't need to fork it unless you want to make some improvements or build upon the base template itself.

Re: Show HN: Django Keel – 10 Years of Django Best Practices in One Template

#4
post #2

This looks great - I have one concern with tools like this - what is the update flow when the template is updated? This is a thing I've been struggling with - what is the best way of delivering such templates. Is a template generator such as this? Would it be best to copy a baseline repo with all options set? Should we fork that base repo and rebase when the baseline updates?

Great question because this has haunted me for over 10 years with cookiecutter. Most of the time I was copy-pasting newer features from running projects back into the template, and then copy-pasting in other running projects. But Keel is based on copier which has a "pull" based approach. It means unlike cookiecutter where you generate project from template once, you can run `copier update` to update your project with…

The fork approach came up at work - because all projects have a lot of boilerplate in common (Terraform, K8s configs, secrets, etc) that can receive improvements upstream from the ops team and it'd be nice if the improvements were easy to apply.

The `copier` thing is nice. I'll sure try it on my next Django project.

Re: Show HN: Django Keel – 10 Years of Django Best Practices in One Template

#5
post #4

Earlier quoted context omitted.

Great question because this has haunted me for over 10 years with cookiecutter. Most of the time I was copy-pasting newer features from running projects back into the template, and then copy-pasting in other running projects. But Keel is based on copier which has a "pull" based approach. It means unlike cookiecutter where you generate project from template once, you can run `copier update` to update your project with…

The fork approach came up at work - because all projects have a lot of boilerplate in common (Terraform, K8s configs, secrets, etc) that can receive improvements upstream from the ops team and it'd be nice if the improvements were easy to apply. The `copier` thing is nice. I'll sure try it on my next Django project.

Definitely, if you find anything that can be improved (even if "docs are not super-clear here), please feel free to raise a PR or report it as an issue.

Re: Show HN: Django Keel – 10 Years of Django Best Practices in One Template

#6
As someone who up to now has mainly watched Django from the sidelines, as it were, this looks great.

What's are your plans for supporting Django v6? (I appreciate it's just gone alpha now, and planned prod release is not for two months.)

Likewise for Python 3.14.

Re: Show HN: Django Keel – 10 Years of Django Best Practices in One Template

#7

As someone who up to now has mainly watched Django from the sidelines, as it were, this looks great. What's are your plans for supporting Django v6? (I appreciate it's just gone alpha now, and planned prod release is not for two months.) Likewise for Python 3.14.

Python 3.14 is there in the repo, though not added in the docs since I haven't tested it with all the infra stuff. The idea is to keep it updated to at the least previous 2 versions of Python/Django at all times so that it's easier for people to keep their projects updated.

Re: Show HN: Django Keel – 10 Years of Django Best Practices in One Template

#8
post #2

This looks great - I have one concern with tools like this - what is the update flow when the template is updated? This is a thing I've been struggling with - what is the best way of delivering such templates. Is a template generator such as this? Would it be best to copy a baseline repo with all options set? Should we fork that base repo and rebase when the baseline updates?

Cruft solves exactly this problem https://cruft.github.io/cruft/

Re: Show HN: Django Keel – 10 Years of Django Best Practices in One Template

#10
post #2

This looks great - I have one concern with tools like this - what is the update flow when the template is updated? This is a thing I've been struggling with - what is the best way of delivering such templates. Is a template generator such as this? Would it be best to copy a baseline repo with all options set? Should we fork that base repo and rebase when the baseline updates?

Great question because this has haunted me for over 10 years with cookiecutter. Most of the time I was copy-pasting newer features from running projects back into the template, and then copy-pasting in other running projects. But Keel is based on copier which has a "pull" based approach. It means unlike cookiecutter where you generate project from template once, you can run `copier update` to update your project with…

[dead]
Post reply on HN