# simple-django-login-and-register: a working Django account flow to read and copy

> This repository is a small Django project that implements the everyday account screens, with login by username, by email or by both, email activation, password reset, remember me and four languages, presented with Bootstrap 4 styling. The judgement is that its value is as a readable reference implementation with modern tooling, not as a dependency you would install into a product, and the exact Django pin is the sharpest edge.

**egorsmkv/simple-django-login-and-register** — An example of Django project with basic user functionality.

- Repository: https://github.com/egorsmkv/simple-django-login-and-register
- Stars: 891 · Forks: 457
- Language: Python
- License: BSD-3-Clause
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/egorsmkv-simple-django-login-and-register

## An example project, not a package to install

The repository describes itself as an example of a Django project with basic user functionality, and that framing decides how to use it. It is not a reusable application in the sense that django-bootstrap4 or a registration app would be. It is a working project you clone, run, read and copy from, with the code laid out so the flows make sense end to end. The licence is BSD-3-Clause, and the repository carries a LICENSE file, a justfile, a pyproject.toml, a pyrefly.toml, requirements.txt and requirements-dev.txt, a uv.lock, a screenshots directory and a source directory, plus GitHub Actions configuration for a CI pipeline. The subject matter is the unglamorous part of a web product that every team rebuilds: the login page, the create account page, the authorized page behind the login, the password reset request, the set new password page and the password change page, each of which is shown as a screenshot in the README so you can see what you get before reading the code.

## Three ways to sign in, plus the recovery paths

The functionality list reads like a checklist of what a Django site needs and is worth reading closely, because it shows how the authentication flow was wired. Logging in can be done with a username and password, with an email and password, or with either an email or a username and password, and there is an optional remember me checkbox. Beyond that the project implements creating an account, logging out, profile activation by email, resetting a password, reminding a username, resending an activation code, changing a password, changing an email address and changing a profile. Two of those deserve a note. Reminding a username is a lookup that helps a user who has forgotten which identifier they registered with, which only makes sense because the login form accepts both. Resending an activation code matters because email delivery is the weak point of any activation flow, and a project that has a second button for it has clearly met that failure. The pages are translated into English, French, Simplified Chinese and Spanish, and the README points to a separate repository for the case where you need dynamic URLs carrying the language code.

## Two settings trees, one for development and one for production

Configuration is split by environment, and the split is where you will spend your first hour. The README asks you to edit source/app/conf/development/settings.py if you want to develop the project, and source/app/conf/production/settings.py if you want to run it in production, and it names the three things these files handle, the connection to the database, the connection to an SMTP server, and other options. The SMTP part is not optional decoration, because the account activation and password reset flows both send mail, so a working mail path is a prerequisite for testing them at all. After configuration comes the standard two steps, applying the migrations and running the server. In production you also collect the static files, which matters here because the interface is styled with Bootstrap 4, so the CSS has to be gathered into a location the web server can serve. The project uses django-bootstrap4, which is listed in the dependencies alongside Django itself.

## Getting it running with uv and Python 3.13

The install path uses uv rather than pip and a bare virtualenv, and the README documents both the uv workflow and the plain requirements files, so you can work either way. The clone and the environment:

```bash
git clone https://github.com/egorsmkv/simple-django-login-and-register
cd simple-django-login-and-register
```

```bash
uv venv --python 3.13

source .venv/bin/activate
```

Then the dependencies, with the requirement files offered as an alternative:

```bash
uv sync --upgrade
```

Finally the database and the server:

```bash
python source/manage.py migrate
```

```bash
python source/manage.py runserver
```

Note that manage.py lives under source/, so every command is run with that path prefix, and that the project metadata requires Python 3.12 or newer while the virtual environment recipe asks for 3.13 specifically.

## ruff, mypy and pyrefly all in one justfile

The tooling is the most modern thing about the project and the part most likely to be useful to a reader. A justfile at the root exposes four recipes, and the fmt recipe is the one the README highlights:

```
check:
	ruff check

mypy:
	cd source && PYTHONPATH=. mypy . --check-untyped-defs

pyrefly:
	pyrefly check

fmt:
	ruff format
	find source/ -name '*.html' | xargs djade --target-version '5.2'
```

Three details are worth noting. The mypy recipe runs from inside the source directory with PYTHONPATH set, because the Django settings module lives there, and the pyproject configures the mypy Django plugin with django_settings_module set to app.settings. The fmt recipe does not stop at Python, it pipes the HTML templates through djade so the markup is formatted to a target version as well. And the project runs two type checkers in parallel, mypy with django-stubs and pyrefly, which is an unusual choice and a cheap way to catch disagreements between them. The dev extra installs django-stubs, ruff, pyrefly and djade, and the ruff configuration sets a line length of 88, selects the E, F and I rule sets, and fixes everything it can.

## Pinned dependencies are the trade-off

The dependencies are pinned to exact versions, and that is the decision that needs a judgement. The project metadata requires Python 3.12 or newer and lists Django at 6.1.2 and django-bootstrap4 at 26.3, and the requirements file repeats the same two pins. Exact pins make the example reproducible, which matters when someone clones it to study it, and they also make a security patch an explicit human action, because nothing will float the version forward for you. There is a second oddity in the numbering. The project metadata carries version 0.4.9, while the published releases are numbered v6.0 from 2026-01-06, v5.2 from 2025-10-02 and v5.1 from 2025-06-11. The two schemes plainly do not describe the same thing, so if you are tracking this project over time, the git tags and the metadata version will not tell the same story. A uv.lock file is committed, which pins the full transitive dependency set for reproducible installs.

## Licence, CI and the life of the repository

On the paperwork the project is permissive, with a BSD-3-Clause licence and a LICENSE file at the root, which is a licence you can take code from without much ceremony. The CI configuration lives in .github as a workflow file for a pipeline, and the README carries a badge for it, so the test run is visible without opening the tree. The activity record is healthy enough to be interesting. The last push was on 2026-10-18, the repository is not archived, and three releases appeared in the second half of 2025 and the start of 2026. What the project is not, however, is a framework with a deprecation policy or a security response process, and the README says nothing about either. The realistic way to use it is to read it. Take the flow of the account screens, take the settings split, take the tooling configuration, and take the templates, then implement the pieces you need inside a project you actually maintain.

## Conclusion

This project suits a developer who wants a concrete, readable example of how Django account flows fit together, including activation by email, password reset and multilingual pages, and it suits a team that prefers to read working code over adopting a packaged authentication app. It does not suit a product team that wants an installable, upgradeable authentication component, because the repository is an example project with pinned dependencies rather than a library, and it is a poor fit if you need social login, two factor authentication or an account model beyond the default one. Before you copy from it, check the pinned Django version against your own project, because the requirements pin an exact release, and read the two settings files under source/app/conf, since the database and SMTP configuration differs between the development and production variants.

## FAQ

### How do I run the simple-django-login-and-register project locally?

Clone the repository, create a virtual environment with uv venv --python 3.13 and activate it with source .venv/bin/activate, then install the dependencies with uv sync --upgrade. Apply the migrations with python source/manage.py migrate and start the development server with python source/manage.py runserver.

### Which login methods does the example support?

The README lists login with a username and password, login with an email and password, and login with either an email or a username and password, plus an optional remember me checkbox. The project also covers account creation, log out, profile activation by email, password reset, username reminder, resending an activation code, and changing the password, email and profile.

### Which languages are the pages translated into?

The project is multilingual in English, French, Simplified Chinese and Spanish. If you need dynamic URLs that carry the language code, the README points to a separate repository, simple-django-login-and-register-dynamic-lang, for that case.

## Sources

- [egorsmkv/simple-django-login-and-register on GitHub](https://github.com/egorsmkv/simple-django-login-and-register)
- [Issues](https://github.com/egorsmkv/simple-django-login-and-register/issues)
- [License: BSD-3-Clause](https://github.com/egorsmkv/simple-django-login-and-register/blob/master/LICENSE)
- [README](https://github.com/egorsmkv/simple-django-login-and-register/blob/master/README.md)
- [Releases](https://github.com/egorsmkv/simple-django-login-and-register/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/egorsmkv-simple-django-login-and-register