Do you guys find Django includes enough batteries? Why or why not?
I find myself using Cookiecutter Django [^1] more often than not, better auth, a bunch of boilerplate configs, S3 and email setups if you want, and other stuff rather than have to jiggle with "Django infra" myself
[^1]: https://github.com/cookiecutter/cookiecutter-django
In Django 6cookiecutter
cookiecutter-django
Python2015–2025
cookiecutter / cookiecutter-django
cookiecutter-django
Cookiecutter Django is a framework for jumpstarting production-ready Django projects quickly.
25Distinct people
27Mentions
1Explicit recommenders
13.6KGitHub stars
What to know before exploring
What it is
Cookiecutter Django is a framework for jumpstarting production-ready Django projects quickly.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
My favorite opinionated boilerplate for new Django projects: https://github.com/pydanny/cookiecutter-django/ From the author of the great Two Scoops of Django series.…
adpirz used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year27 dated mentions
Observed mentions: 2015-03-25 11:56:07 UTC to 2025-12-04 22:23:20 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 1 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Cookiecutter Django
Powered by Cookiecutter, Cookiecutter Django is a framework for jumpstarting
production-ready Django projects quickly.
Documentation: https://cookiecutter-django.readthedocs.io/en/latest/
See Troubleshooting for common errors and obstacles
If you have problems with Cookiecutter Django, please open issues don't send
emails to the maintainers.
Features
For Django 6.0
Works with Python 3.14
Renders Django projects with 100% starting test coverage
Twitter Bootstrap v5
12-Factor based settings via django-environ
Secure by default. We believe in SSL.
Optimized development and production settings
Registration via django-allauth
Comes with custom user model ready to go
Optional basic ASGI setup for Websockets
Optional custom static build using Gulp or Webpack
Send emails via Anymail (using Mailgun by default or Amazon SES if AWS is selected cloud provider, but switchable)
Media storage using Amazon S3, Google Cloud Storage, Azure Storage or nginx
Docker support using docker-compose for development and production (using Traefik with LetsEncrypt support)
Procfile for deploying to Heroku
Instructions for deploying to PythonAnywhere
Run tests with unittest or pytest
Customizable PostgreSQL version
Default integration with pre-commit for identifying simple issues before submission to code review
Optional Integrations
These features can be enabled during initial project setup.
Serve static files from Amazon S3, Google Cloud Storage, Azure Storage or Whitenoise
Configuration for Celery and Flower (the latter in Docker setup only)
Integration with Mailpit or Mailtrap Local for local email testing
Integration with Sentry for error logging
Constraints
Only maintained 3rd party libraries are used.
Uses PostgreSQL everywhere: 14 - 18 (MySQL fork also available).
Environment variables for configuration (This won't work with Apache/mod_wsgi).
Support this Project!
This project is an open source project run by volunteers. You can sponsor us via OpenCollective or individually via GitHub Sponsors:
Daniel Roy Greenfeld, Project Lead (GitHub, Patreon): expertise in Django and AWS ELB.
Fabio C. Barrionuevo, Core Developer (GitHub): expertise in Python/Django, hands-on DevOps and frontend experience.
Bruno Alla, Core Developer (GitHub): expertise in Python/Django and DevOps.
Nikita Shupeyko, Core Developer (GitHub): expertise in Python/Django, hands-on DevOps and frontend experience.
Projects that provide financial support to the maintainers:
Two Scoops of Django
Two Scoops of Django 3.x is the best ice cream-themed Django reference in the universe!
PyUp
PyUp brings you automated security and dependency updates used by Google and other organizations. Free for open source projects!
Usage
Let's pretend you want to create a Django project called "redditclone". Rather than using startproject
and then editing the results to include your name, email, and various configuration issues that always get forgotten until the worst possible moment, get cookiecutter to do all the work.
First, get Cookiecutter. Trust me, it's awesome:
uv tool install "cookiecutter>=1.7.0"
Now run it against this repo:
uvx cookiecutter https://github.com/cookiecutter/cookiecutter-django
You'll be prompted for some values. Provide them, then a Django project will be created for you.
Warning: After this point, change 'Daniel Greenfeld', 'pydanny', etc to your own information.
Answer the prompts with your own desired options. For example:
Cloning into 'cookiecutter-django'...
remote: Counting objects: 550, done.
remote: Compressing objects: 100% (310/310), done.
remote: Total 550 (delta 283), reused 479 (delta 222)
Receiving objects: 100% (550/550), 127.66 KiB | 58 KiB/s, done.
Resolving deltas: 100% (283/283), done.
project_name [My Awesome Project]: Reddit Clone
project_slug [reddit_clone]: reddit
description [Behold My Awesome Project!]: A reddit clone.
author_name [Daniel Roy Greenfeld]: Daniel Greenfeld
domain_name [example.com]: myreddit.com
email [daniel-greenfeld@example.com]: pydanny@gmail.com
version [0.1.0]: 0.0.1
Select open_source_license:
1 - MIT
2 - BSD
3 - GPLv3
4 - Apache Software License 2.0
5 - Not open source
Choose from 1, 2, 3, 4, 5 [1]: 1
Select username_type:
1 - username
2 - email
Choose from 1, 2 [1]: 1
timezone [UTC]: America/Los_Angeles
windows [n]: n
Select an editor to use. The choices are:
1 - None
2 - PyCharm
3 - VS Code
Choose from 1, 2, 3 [1]: 1
use_docker [n]: n
Select postgresql_version:
1 - 18
2 - 17
3 - 16
4 - 15
5 - 14
Choose from 1, 2, 3, 4 [1]: 1
Select cloud_provider:
1 - AWS
2 - GCP
3 - None
Choose from 1, 2, 3 [1]: 1
Select mail_service:
1 - Mailgun
2 - Amazon SES
3 - Mailjet
4 - Mandrill
5 - Postmark
6 - Sendgrid
7 - Brevo (formerly SendinBlue)
8 - SparkPost
9 - Other SMTP
Choose from 1, 2, 3, 4, 5, 6, 7, 8, 9 [1]: 1
Select rest_api [None]:
1 - None
2 - DRF
3 - Django Ninja
Choose from 1, 2, 3 [1]: 1
use_async [n]: n
Select frontend_pipeline:
1 - None
2 - Django Compressor
3 - Gulp
4 - Webpack
Choose from 1, 2, 3, 4 [1]: 1
use_celery [n]: y
Select mail_catcher:
1 - None
2 - Mailpit
3 - Mailtrap Local
Choose from 1, 2, 3 [1]: 1
use_sentry [n]: y
use_whitenoise [n]: n
use_heroku [n]: y
Select ci_tool:
1 - None
2 - Travis
3 - Gitlab
4 - Github
Choose from 1, 2, 3, 4 [1]: 4
keep_local_envs_in_vcs [y]: y
debug [n]: n
Enter the project and take a look around:
cd reddit/
ls
Create a git repo and push it there:
git init
git add .
git commit -m "first awesome commit"
git remote add origin git@github.com:pydanny/redditclone.git
git push -u origin main
Now take a look at your repo. Don't forget to carefully look at the generated README. Awesome, right?
For local development, see the following:
Developing locally
Developing locally using docker
Community
Have questions? Before you ask questions anywhere else, please post your question on Stack Overflow under the cookiecutter-django tag. We check there periodically for questions.
If you think you found a bug or want to reque
Read the full README on GitHubWhat Hacker News says
27 sourcesCookiecutter Django: framework for jumpstarting production-ready Django projects
3 points · Open discussionI found that this django setup was an excellent starting point:
https://github.com/cookiecutter/cookiecutter-django
In SaaSavant – SaaS Boilerplatedjangox definitely looks a bit less opinionated and lighter weight than what I normally use for a starter project, which is cookiecutter-django: https://github.com/cookiecutter/cookiecutter-django
It seems to include most everything that djangox does, and a little bit more, and with cookiecutter's setup process, you can strip out much of what you don't want/need.
In Ask HN: What would be your stack if you are building an MVP today?> trying to build a lifeboat for Twitter, Python works, but then modules require builds that break.
> Alternatively, any good resources for the above?
There are many, unbelievably many writeups and tools for Python building and packaging. Some of them are really neat! But paralysis of choice is real. So is the reality that many of the new/all-in-one/cutting edge tools, however superior they may be, just won't get long term support needed to catch on and stay relevant.
When getting started with Python, I very personally like to choose from a few simple options (others are likely to pipe up with their own, and that's great; mine aren't The One Right Way, just some fairly cold/mainstream takes).
1. First pick what stack you'll be using to develop and test software. In Python this is sadly often going to be different from the stack you'll use
Read the rest
to deploy/run it in production, but here we are. There are two sub-choices to be made here:
1.a. How will you be running the Python interpreter itself in dev/test (in other words, what Python language version you will use)? "I just want to use the Python that came with my laptop" is fine to a point, but breaks down a lot sooner than folks expect (again, the reasons for this are variously reasonable and stupid, but here we are). Personally, I like pyenv (https://github.com/pyenv/pyenv) here. It's a simple tool that builds interpreters on your system and provides shell aliases to adjust pathing so they can optionally be used. At the opposite extreme from pyenv, some folks choose Python-in-Docker here (pros: reproducible, makes deployment environments very consistent with dev; cons: IDE/quick build-and-run automations get tricker). There are some other tools that wrap/automate the same stuff that pyenv does.
1.b. How will you be isolating your project's dependencies? "I want to install dependencies globally" breaks down (or worse, breaks your laptop!) pretty quickly, yes it's a bummer. There are three options here: if you really eschew automations/wrappers/thick tools in general, you can do this yourself (i.e. via "pip install --local", optionally in a dedicated development workstation user account); you can use venv (https://docs.python.org/3/library/venv.html stdlib version of virtualenv, yes the names suck and confusing, here we are etc. etc.), which is widely standardized upon and manually use "pip install" while inside your virtualenv, and you can optionally integrate your virtualenv with pyenv so "inside your virtualenv" is easy to achieve via pyenv-virtualenv (https://github.com/pyenv/pyenv-virtualenv); or you can say "hell with this, I want maximum convenience via a wrapper that manages my whole project" and use Poetry or an equivalent all-in-one project management tool (https://python-poetry.org/). There's no right point on that spectrum, it's up to you to decide where you fall on the "I want an integrated experience and to start prototyping quickly" versus "I want to reduce customizations/wrappers/tooling layers" spectrum.
2. Then, pick how you'll be developing said software: what frameworks or tools you'll be using. A Twitter lifeboat sounds like a webapp, so you'll likely want a web framework. Python has a spectrum of those of varying "thickness"/batteries-included-ness. At the minimum of thickness are tools like Flask (https://flask.palletsprojects.com/en/2.2.x/) and Sanic (like Flask, but with a bias towards performance at the cost of using async and some newer Python programming techniques which tend, in Python, to be harder than the traditional Flask approach: https://sanic.dev). At the maximum of thickness are things like Django/Pyramid (https://www.djangoproject.com/). With the minimally-thick frameworks you'll end up plugging together other libraries for things like e.g. database access or web content serving/templating, with the maximally-thick approach that is included but opinionated. Same as before: no right answers, but be clear on the axis (or axes) along which you're choosing.
3. Choose how you'll be deploying/running the software, maybe after prototyping for awhile. This isn't "lock yourself into a cloud provider/hosting platform", but rather a choice about what tools you use with the hosting environment. Docker is pretty uncontentious here, if you want a generic way to run your Python app on many environments. So is "configure Linux instances to run equivalent Python/package versions to your dev/test environment". If you choose the latter, be aware that (and this is very important/often not discussed) many tools that the Python community suggests for local development or testing are very unsuitable for managing production environments (e.g. a tool based around shell state mutation is going to be extremely inconvenient to productionize). I guess nowadays there's an opinionated extreme in the form of serverless environments that eat a zipfile of Python code and ensure it runs somewhere; if you choose to deploy on those, then your decisions about points 1 and 2 above will likely be guided/reassessed based on the opinions of the deployment platform re: what Python versions and packaging techniques are supported.
Yeah, that's a lot of choices, but in general there are some pretty obvious/uncontentious paths there. Pyenv-for-interpreters/Poetry-for-packaging-and-project-management/Flask-for-web-serving/Docker-for-production is not going to surprise anyone or break any assumptions. Docker/raw-venv/Django is going to be just as easy to Google your way through. And if you really don't want to think about things right now and just want to get hello-world in your browser right away, there's always cookiecutters (e.g. https://github.com/cookiecutter/cookiecutter-django).
Again, no one obvious right way (ha!) but plenty of valid options!
Not sure if that's what you were after. If you want a "just show me how to get started"-type writeup rather than an overview on the choices involved, I'm sure folks here or some quick googling will turn up many!
Cookiecutter a framework for jumpstarting Django projects quickly
1 points · Open discussionI use django-cookiecutter [0] for most of my projects as it sets up a myriad of things, saving an incredible amount of time if you need your app to be production ready quick. May be better suited for those experienced with django though.
[0] https://github.com/cookiecutter/cookiecutter-django
In Ask HN: Easiest way to build a CRUD app?Try creating a Django project using the Cookie Cutter Django:
https://github.com/cookiecutter/cookiecutter-django/
Select yes when asked if you want "custom_bootstrap_compilation"
That will configure a gulp task runner that is capable of manage your javascript dependencies, bundle your CSS/JS, and minify your HTML, CSS, JS and images. You will still need to install npm etc. as described here. You will also need to become familiar with how to install and update Node packages.
https://cookiecutter-django.readthedocs.io/en/latest/develop...
In Django 4.0 release candidate 1 releasedPackage it; as a container or as containers that install a RPM/DEB/APK/Condapkg/Pythonpkg (possibly containing a zipapp). Zipapps are fast.
If you have any non-python dependencies, a Pythonpkg only solves for part of the packaging needs.
Producing a packaged artifact should be easy and part of your CI build script.
Here's the cookiecutter-django production docker-compose.yml with containers for django, celery, postgres, redis, and traefik as a load balancer:
https://github.com/pydanny/cookiecutter-django/blob/master/%...
Cookiecutter-django also includes a Procfile.
With k8s, you have an ingress (~load balancer + SSL termination proxy) other than traefik.
You can generate k8s YML from docker-compose.yml with Kompose.
I just found this which describes using GitLab CI with Helm:
https://davidmburke.com/2020/01/24/deploy-django-with-helm-t.
Read the rest
..
What is the command to scale up or down? Do you need a geodistributed setup (on multiple providers' clouds)? Who has those credentials and experience?
How do you do red/green or rolling deployments?
Can you run tests in a copy of production?
Can you deploy when the tests that run on git commit pass?
What runs the database migrations in production; while users are using the site?
If something deletes the whole production setup or the bus factor is 1, how long does it take to redeploy from zero; and how much manual work does it take?
CI + Ansible + Terraform + Kubernetes.
Whatever tools you settle on, django-eviron for a 12 Factor App may be advisable.
https://github.com/joke2k/django-environ
The Twelve-Factor App:
https://12factor.net/
Thanks! Yeah, I think it is important for a side project to be able to start working on the actual code as quickly as possible. It is not too much of a problem to set up all these fancy frontend tools before going into production.
If it's just a weekend project, it's also fine to just include some external JS libraries directly.
What I seem to get away with is using Cookiecutter Django's* simple build pipeline based on npm and gulp. It is basically set up from the moment you finish the project initialization. It even comes with live reloading.
The pipeline is based on these files:
https://github.com/pydanny/cookiecutter-django/blob/master/%...
https://github.com/pydanny/cookiecutter-django/blob/master/%...
* https://github.com/pydanny/cookiecutter-django
In Using VueJS Alongside DjangoYou are looking for a "boilerplate" than.
There are some e.g. for Django I think. Have a look at this: https://github.com/pydanny/cookiecutter-django
And stripe and google analytics are made to integrate easily, that shouldn't need a boilerplate.
For newsletters external tools are better suited so you don't run in to spam filters too much.
In Ask HN: Do you use a SaaS starter-kit?Another +1 for sentry. I used it (basically accidentally) for a year because it's part of the cookiecutter-django framework[1]. I don't think there was a single issue with it the whole time we used it.
[1] https://github.com/pydanny/cookiecutter-django
In Ask HN: How do you handle logging?My favorite opinionated boilerplate for new Django projects:
https://github.com/pydanny/cookiecutter-django/
From the author of the great Two Scoops of Django series.
https://www.twoscoopspress.com/products/two-scoops-of-django...
Two great ways to avoid some newbie mistakes. Although some could argue diving into boilerplate without understanding it is in fact a newbie mistake itself.
In Django Newbie MistakesAs described by the documentation, Django applications are “a Python package that provides some set of features”, reusable, and are “a combination of models, views, templates, …, URLs, etc”. What this approach describes is not standard at all to the Django app structure. Some cons to this include: no ability to make new versions of an app and use them concurrently, removing set standards and confusing ANY new engineer that must work on the project, no compartmentalization of business logic, etc etc. There is a reason why Django is structured the way it is. Removing the battle tested skeleton may mean it is not the web framework for your particular project.
For a detailed explanation of what Django app's are and why they are structured the way they are please refer to the `2. Intro to Django Applications` section of https://medium.com/@djs
Read the rest
tein/modern-django-part-2-rest-apis-a...
For any new Django engineers reading this, I would point you towards https://github.com/pydanny/cookiecutter-django for the best / most complete structure.
Showing the 15 most recent of 27 sources. Enable JavaScript to search and browse every indexed mention.