# cookiecutter-django-rest is a Django REST template whose last release was in 2017 > This cookiecutter template scaffolds a dockerized Django REST API with authentication, a users app, docs and tests, and the repository pushes regularly while carrying release tags from 2017. What you generate is current; what the project promises about a version is not. **agconti/cookiecutter-django-rest** — Build best practiced apis fast with Python3 - Repository: https://github.com/agconti/cookiecutter-django-rest - Website: http://agconti.github.io/cookiecutter-django-rest/ - Stars: 1,601 · Forks: 188 - Language: Python - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/agconti-cookiecutter-django-rest ## What you get is a working API, not a blank Django project The pitch in the README is aimed at someone with a deadline who cares about the result. It says scaffolding takes seconds and hands you authentication, user accounts, documentation and tests, at which point you add your own resources and ship. That framing sets expectations better than most templates do. Unlike a blank Django project, the template ships several application files. This gives you a working users app with authentication and a documented API surface before you write a line of business logic. The four links in that paragraph point into the generated repository, and their URLs reveal the template variables. The README's hrefs are written with `{{cookiecutter.github_repository_name}}` and `{{cookiecutter.app_name}}` in them, so the documentation, the users views and the view tests are all named after what you answered at generation time. `docs/api/authentication.md` and `docs/api/users.md` are files in your project, not in the template, once it has been rendered. So the authentication and users app are documentation-driven from the start. Whoever picks the project up next finds the auth story written down rather than inferred from a decorator. There is also a `docs/` directory distinct from the API docs referenced there, and a test file per view in `users/test/test_views.py`, which tells you the tests are organised per app rather than in a single test package. ## The stack is pinned forward, not backward The Highlights list is where the actual constraints live, and they are aggressive: - Modern Python development with Python 3.13+ - Bleeding edge Django 5.0+ - Fully dockerized, local development via docker-compose - PostgreSQL 16.4+ - Complete Django Rest Framework integration Read together, these are minimums, not versions it was tested against. Python 3.13 and Django 5.0 as floors means the generated project will refuse to run on an older interpreter or an older Django, which is a reasonable choice for a project you are starting now and a poor one if you need the template to fit an existing platform. PostgreSQL 16.4+ as a floor means there is no SQLite fallback. That is the right default for something claiming best practice, and it also means your first local run needs the docker-compose stack up rather than a single file. The Django Rest Framework integration is listed as complete, which is the claim to verify against your needs: the README does not enumerate which parts of DRF are wired, so the serializers, the pagination settings and the throttling defaults are things you read in the generated code rather than in this document. The README describes the foundation as a slim but robust one, just enough to maximize productivity and nothing more. That is a statement about scope, and it is the one to hold the template to: if a generated project arrives with features you did not ask for, the template did not keep its side of that. ## pyup.io is the dependency policy, and it is the file to read One of the two files at the repository root other than the template is `.pyup.yml`, and the README points at it as the mechanism for always current dependencies and security updates. pyup.io is a service that opens pull requests against your requirements when a dependency updates or a security advisory lands, which for a template is a particular kind of responsibility. The template's dependencies are not the template's runtime; they become your runtime at generation time, and they age the moment the project is generated. So the question the `.pyup.yml` answers is how aggressively the template opens those pull requests against itself. A template that updates nightly against its own test suite is a template that tends to be usable with current versions. One that does not is a template that generates a working project once and then quietly lags. That file is small and it is the most informative artifact in the repository after `cookiecutter.json`. If you are evaluating a cookiecutter template, reading its configuration beats reading its README, because the README describes an intention and the configuration describes a policy. The `.github/` directory holds a workflow at `push.yaml`, and the build badge in the README points at that file on the `master` branch, so the template's own tests run on push. ## cookiecutter.json is the interview you answer at generation time The template directory is named `{{cookiecutter.github_repository_name}}`, which is the cookiecutter convention: the directory whose name is a template variable is the one rendered into your new project. `cookiecutter.json` at the root is the set of questions cookiecutter asks, and the two variable names visible in the README's links tell you at least two of them. `github_repository_name` becomes the project directory name, and `app_name` becomes the Django application package. The `app_name` choice is the one with lasting consequences, because it names the users app that ships with the generated project. If you answer `users` you get `users/views.py` and `users/test/test_views.py` as shown. If you answer something else, those paths follow it, and the pre-written API documentation references follow too. Scaffolding is two commands: ```bash brew install cookiecutter cookiecutter gh:agconti/cookiecutter-django-rest ``` The `gh:` prefix means the source is fetched from GitHub rather than from a PyPI package, so there is no version argument in the quick start. You get whatever is on the default branch at the moment you run it. That is the same fact as the release history, expressed at generation time, and it is worth being clear-eyed about: there is no `cookiecutter-django-rest==0.8.0` you can install, only a branch tip. ## A Travis file reference next to a GitHub Actions badge There is a small inconsistency in the README that tells you about the repository's history. The Highlights list links to continuous integration by pointing at `.travis.yml` inside the generated project. The build badge at the top of the README points at `.github/workflows/push.yaml` on `master`. So the template's own CI runs on GitHub Actions, while the CI it generates for your project is Travis. That is what you would expect from a template whose history predates GitHub Actions, and it has a practical consequence: the project you generate starts life with a CI configuration on a service many teams have stopped using, and you will be replacing it in your first hour. That is a small thing, but it is the kind that makes a template feel dated on contact. The generated project is otherwise current, down to PostgreSQL 16.4 and Python 3.13, so the CI file is the one artifact where the age shows. The generated `.travis.yml` does at least tell you the template expects tests to run as part of CI, matching the claim about starting with full test coverage. The root also carries CODE_OF_CONDUCT.md and LICENSE, and the licence is MIT. ## What a template like this commits you to The honest framing of a cookiecutter template is that it optimises for the first hour and makes no claim about the tenth. You get a repository where authentication, the users app, the docs and the tests already agree with each other, which is genuinely valuable and is the reason to use a template rather than startproject. You also get a set of files that now belong to you, which nobody will fix for you. That is different from a library, and the difference matters for upgrade decisions. There is no patch release that fixes a bug in your generated project; the only path is to diff the template's current output against what you have and pull across the pieces you want. That is a manual operation, and it is only tractable if you have not heavily modified the files you are pulling. For the same reason, the generated project is worth reading before you extend it. The DRF settings, the auth backends, the serializer conventions and the pagination defaults are all decisions someone else made for you, expressed in code that you now maintain. Release history supports the caution. Tags are 0.8.0 from 2017-12-28, 0.7.0 from 2017-10-16 and 0.6.0 from 2016-12-19. The last push was on 2026-10-07 and the repository is not archived, so maintenance is happening on the branch and not on the release stream. The homepage is http://agconti.github.io/cookiecutter-django-rest/, which is where the full documentation of the generated layout lives. ## Conclusion Adopt cookiecutter-django-rest if you want a Django REST API scaffolded in seconds with authentication, a users app, tests and Docker Compose already wired, and you are content to own every file it generates. It is the wrong choice if you need a maintained release stream to pin against, because the newest tag is 0.8.0 from 2017 while the last push was on 2026-10-07, so there is no version to track. Before generating, read `cookiecutter.json` and the `.pyup.yml` file, since the template's answers at generation time and its dependency update policy determine what you actually get, and delete the `.travis.yml` reference when you move to the GitHub Actions workflow the badge points at. ## FAQ ### How do I generate a project from cookiecutter-django-rest? Install cookiecutter, then run cookiecutter gh:agconti/cookiecutter-django-rest. The gh: prefix fetches from GitHub, so you get the current default branch rather than a pinned release. ### What does the cookiecutter-django-rest template require? Python 3.13 or later, Django 5.0 or later and PostgreSQL 16.4 or later, with Django Rest Framework integrated. Local development is via docker-compose rather than a bare SQLite setup. ### What does the template generate out of the box? Authentication, a users app, API documentation under docs/api and per-view tests, with the app and repository names taken from your cookiecutter.json answers. ### How are dependencies kept current in cookiecutter-django-rest? Through pyup.io, configured by the .pyup.yml file at the repository root, which opens pull requests when dependencies or security advisories change. ### What is the latest released version of cookiecutter-django-rest? 0.8.0, tagged on 2017-12-28. The last push was on 2026-10-07, so the branch is maintained even though no release has been cut since 2017. ## Sources - [agconti/cookiecutter-django-rest on GitHub](https://github.com/agconti/cookiecutter-django-rest) - [License: MIT](https://github.com/agconti/cookiecutter-django-rest/blob/master/LICENSE) - [Project website](http://agconti.github.io/cookiecutter-django-rest/) - [README](https://github.com/agconti/cookiecutter-django-rest/blob/master/README.md) - [Releases](https://github.com/agconti/cookiecutter-django-rest/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/agconti-cookiecutter-django-rest