cookiecutter-django-vue, a Docker and GraphQL Django plus Vue project template

A project skeleton with the infrastructure decisions already made

cookiecutter-django-vue is a template for Django and Vue projects, powered by Cookiecutter and inspired by Cookiecutter Django.

The value proposition is the set of decisions it makes for you. The stack is Docker and twelve factor conventions for deployment, Nginx as the server, Vue with vue-cli and PWA support on the frontend, Django on the backend, PostgreSQL as the database, and the API exposed as REST or GraphQL. Every one of those choices would otherwise be an afternoon of setup, and several of them, particularly the Nginx and Compose arrangement, are the kind of thing you only get right once.

It is a template in the strict Cookiecutter sense. The repository has a cookiecutter.json at the root, a hooks/ directory, a tests/ directory with pytest-cookies, and a directory whose name is itself a Jinja expression, {{cookiecutter.project_slug}}, which becomes the generated project directory. So the generated project is produced from the template with your answers substituted into it.

The topics list names the ingredients: apollo, django, docker-compose, graphene for GraphQL, pwa, vue, vue-cli and webpack. That last set of three is the first thing to notice if you are starting a new project today, and we will come back to it.

The prompts decide the shape of the generated project

Usage is a two step affair. You get cookiecutter first, then run it against the repository:

    $ pip install cookiecutter
    $ cookiecutter gh:vchaptsev/cookiecutter-django-vue

You are then prompted for values, and a project is created for you. The README shows the shape of the interaction, and it is worth reading as a specification of what the template will and will not do for you.

The first group is project identity: project_name, project_slug, description, author and email. The second group is general, and the first real choice is the API style:

    ====================== GENERAL ====================== [ ]:
    Select api:
    1 - REST
    2 - GraphQL
    Choose from 1, 2 [1]: 2
    backups [y]: y

The third group is integrations, where the answer to each question toggles a feature in the generated project:

    ==================== INTEGRATIONS =================== [ ]:
    use_sentry [y]: y
    use_mailhog [y]: y
    Select analytics:
    1 - Google Analytics
    2 - Yandex Metrika
    3 - None
    Choose from 1, 2, 3 [1]: 2

The integrations the README lists as optional and enabled during initial setup are MailHog for local email testing, Sentry for frontend and backend error logging, Google Analytics or Yandex Metrika for web analytics, and automatic database backups. Choosing GraphQL over REST at the prompt is a decision you cannot cheaply undo later, because it determines the API layer of the generated backend, which is where the apollo and graphene dependencies in the project come from.

The generated project needs a formatting pass before it is clean

The README is candid about a rough edge in the generated output: project creation will cause some odd newlines and linter errors, and it recommends running autopep8 over the backend and the frontend lint fix afterwards.

    $ pip install autopep8
    $ autopep8 -r --in-place --aggressive --aggressive backend
    $ cd frontend && npm i && npm run lint --fix

This is a small thing but a telling one. A template that ships a backend that does not pass its own linter configuration is a template that has drifted from the tools it configures, and the fix is left to the person generating the project. The two aggressive passes are not cosmetic either, since the odd newlines the README mentions are a formatting artefact that plain autopep8 would not necessarily clean up.

The practical sequence for a new user is therefore: generate, format, install, run. The formatting step is part of the intended workflow rather than a workaround, and the npm i step in the frontend is where the JavaScript dependencies land.

Docker Compose for development, a separate file for production

Running the project is a Compose command, and there are two of them.

For local work the README gives:

    $ docker-compose up --build

For production you need to fill out the .env file and use the production compose file:

    $ docker-compose -f docker-compose-prod.yml up --build -d

The split is the twelve factor approach the README lists as a feature. Development and production use different Compose files, and the production path expects a populated .env, so the configuration comes from the environment rather than from a checked-in file.

For a Django and Vue application this arrangement buys you a specific thing: the frontend is built and served by Nginx, the backend runs as a service behind it, and PostgreSQL runs as a third service, with the three wired together by Compose rather than by your laptop's setup. The development command uses --build so the images are rebuilt after the first run, which is what you want after a dependency change in the generated project, and the production command adds -d to detach so the stack survives your shell closing.

The .env step is the one to not skip. The README states plainly that you will need to fill out the .env file for production, and an unfilled .env is the most common reason a generated project starts and then misbehaves.

A template whose toolchain has aged, and the tests that guard it

The version record is the context you need for any decision about this template.

The listed releases are 0.8.0 in November 2017, 0.9.0 in December 2017 and 2.0.0 in September 2018, and the repository has no GitHub releases beyond that. The last push to master was on 2026-04-13. So the tree is being touched, while the published versions stopped a long time ago, and the versions jumped from 0.9.0 to 2.0.0 without an intervening 1.x.

The toolchain named in the README is the more actionable signal. The frontend is Vue with vue-cli, and the project topics list webpack. That is the pre-Vite generation of the Vue toolchain, and a template built around it will need real work before it runs on a current Vue release, with vue-cli itself in maintenance mode. Same for the backend: the template is from the Django 2.x era.

What has been kept current is the testing of the template itself. The requirements.txt pins cookiecutter 1.7.2, and for testing, pytest 5.4.1 and pytest-cookies 0.5.1. pytest-cookies is the plugin that runs cookiecutter against a template and asserts the result, so the repository can check that generation still works even as the generated project ages. There is a .travis.yml for continuous integration, which is the era-appropriate choice and a hint about how the project is verified.

The BSD 3-Clause licence is permissive and requires only that the notice is kept.

What to pick instead, and when this template still wins

The honest comparison is with the ecosystem rather than with one project. Cookiecutter Django, which this template is inspired by, is the reference point for a Django backend with a cookiecutter-generated layout, and it deliberately does not include a JavaScript frontend, so a team wanting Django plus a modern single page frontend has to make that combination themselves, which is exactly the gap this template fills.

Against a plain manual setup, the difference is the whole point. With this template, the Compose file, the Nginx configuration, the Django settings split for development and production, the Vue and PWA scaffolding and the optional integrations arrive already wired to each other. Doing that by hand is a day of work and produces a project that only the person who wrote it understands.

Against a modern JavaScript framework template, the difference is the other direction. If your frontend team expects Vite, a typed build, and a current Django release, this template hands you vue-cli and webpack and a dependency tree from 2018, and the upgrade is yours to do. The same applies on the backend side.

So the fit is narrow and clear. This template is for a team that wants the Django and Vue shape of project decided for them, is prepared to own the dependency upgrade, and values the optional integrations, particularly the automatic database backups, being wired up on day one. If you need the current toolchain instead, a Vue and Django project with a modern build setup and no legacy scaffolding is the better starting point, and the value of this repository is the shape it demonstrates rather than the code it generates.

Editorial conclusion

Adopt cookiecutter-django-vue if you are starting a Django and Vue project and want the Docker Compose, Nginx and PostgreSQL wiring decided for you, with a choice of REST or GraphQL and a set of integrations you can switch on at generation time. Do not adopt it for a project that needs a current Django and Vue toolchain, since the template names vue-cli and webpack rather than Vite, and the last push was on 2026-04-13 with the last tagged release being 2.0.0 in 2018, so you will be doing the dependency upgrade work yourself. Before you generate, read the prompt list and decide the API style and integrations up front, since those answers shape the generated project, and check the generated .env file and the docker-compose-prod.yml path before anything reaches a server.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. Releases
5. vchaptsev/cookiecutter-django-vue on GitHub