Django-School-Management: admissions, fees and a load test stack in one repository

The application surface

The working components list in the project notes is the best description of what the software does, and it reads like a specification rather than a feature list. An applicant can create an admission application by hand, which saves the candidate as an offline admission candidate, and there is an online application where the payment and the admission process are handled automatically. The system then handles payment, admission, rejection, and updating a candidate's status after communication, which is the loop a real admissions office runs on.

On the academic side, a student can be assigned to an academic batch and a class, there is a counselling dashboard with data visualisation and downloadable PDF reports, and the curriculum side covers CRUD for departments, subjects, teachers, academic sessions and semesters, including importing subjects from a CSV file. There are list views for teachers and students, CRUD for designations, and user management with user groups and permissions.

The stack is Django with bootstrap-4 and JavaScript, and the project calls itself a fullstack school management project. The repository layout follows that shape, with a config directory, a context_processors directory, a deploy directory, the main application package, an envs directory for environment configuration, a monitoring directory, a permission_handlers directory, templates, static files, tests and a utilities package.

PostgreSQL, Redis and a Celery worker

Two services are required before the project will do anything: a PostgreSQL database and a Redis instance that is up and running. Redis is not optional decoration. Celery is installed and the worker is what executes the background work, and the project notes describe the setup in two steps: install Redis alongside Celery, and then run the worker command in a separate terminal while the Django server is running.

The Linux route is to start the server with the redis-server command, and the Windows route is to download a Redis build and run the redis-server and redis-cli executables. The Compose file wires the same pieces together with a Redis service, a Postgres service, a Django service, a Celery service, and Prometheus and Alertmanager alongside, all on a shared network. The Celery service command is the same worker invocation as the manual instructions:

  celery:
    build: .
    command: celery -A config worker -l INFO

The Django service mounts the repository into the container, mounts separate volumes for static files and media, and runs a pre-deploy script before starting the development server on port 8000.

Setup is four commands and an env file

The installation section is short enough to read in one go. You go to the project folder, install the dependencies with pip install -r requirements.txt, create a .env file under the envs folder using the .env.example template for your credentials, run the migrations with python manage.py migrate, and then start the server with python manage.py runserver. The notes also say to create a superuser for testing.

The requirements file is worth a look before you install, because it is a long, mostly pinned list. It includes Django 4.2, Celery 5.3.1, the Braintree client, Django REST framework with the schema generator and the JWT package, Graphene for GraphQL, django-prometheus and the Prometheus client, plus a full development toolchain: pytest with pytest-django and factory-boy for tests, coverage, black, isort, flake8, mypy, bandit and safety. There are also the usual application packages, from django-allauth and django-environ through the tables, import-export, mptt and taggit libraries, and a few locale-specific ones such as arabic-reshaper and dateparser, which fits a system intended for schools in more than one language.

Fixtures, and a load order that matters

The project ships fixture files so you can see the system with data in it rather than with empty tables. The pattern is the standard Django one, running a management command that names the fixture path, and the notes give the order to load them in, which starts with the teachers fixtures, then the academics fixtures, and then five student fixture files covering offline applications and the online admitted, paid, rejected and unpaid states.

The order is not a suggestion. The students fixtures describe candidates against teachers and academic records, so loading them before the teachers and academics data produces rows with nothing to point at. The two student fixture paths in the list are written with Windows backslashes, which is a small portability wrinkle in the documentation rather than in the code, but it is the kind of detail that stops a copy and paste on a Linux machine.

There is also a seed script at the top level of the repository, and a fixtures helper the project links to for the general concept of loading initial data.

Payments run through a Braintree sandbox

The money path depends on a Braintree account, and the project points you at a sandbox rather than at a live gateway, which is the right way to try it. The additional resources section says to create a Braintree sandbox account, and the testing section gives the details you need to exercise a card payment: you apply the card information at the admission link, the card number is 5555555555554444, and the expiry can be any valid future date.

That is a small set of instructions, and it works because the sandbox accepts a well known test number rather than a real card. It is worth understanding what it does and does not prove, though. A successful sandbox charge tells you the request shape, the tokenisation and the web flow are wired up; it does not tell you what happens with a declined card, a failed webhook or a currency you are not expecting, and those are the paths that break in production. The candidate status handling, where a payment result feeds back into whether someone is admitted, paid, rejected or unpaid, is where most of the real behaviour lives.

The performance stack that ships with the project

Unusually for an application repository, this one includes a load test environment, in a Compose file named for the purpose. Four things run. Locust is the load test, configured to autostart with 200 users for 10 minutes with its web interface on port 8089. A Locust exporter scrapes the Locust statistics and exposes them as Prometheus metrics on port 9646. Prometheus scrapes that exporter, and optionally the Django metrics endpoint, on port 9091. And Grafana comes up pre-provisioned with Prometheus and the Locust dashboard already wired, on port 3010.

The whole stack starts with one command from the project root:

docker compose -f docker-compose.perf-test.yml up --build

The dashboards are then on localhost, with Grafana on 3010 with the default admin credentials, and the Performance and Locust view in Grafana shows status, users, requests per second, response times and failures. For a project whose stated selling point is the application rather than the benchmarking, this is the most transferable thing in the repository: a load test harness that anyone can run against their own deployment and compare against.

The container image and the licensing gap

The Dockerfile shows the production shape. It is based on a slim Python 3.11 image, installs the build dependencies needed for C extensions such as psutil on architectures without a wheel, and installs gunicorn at a pinned version. The uWSGI environment variables are set in the image as well, with the workers and threads count configurable:

ENV UWSGI_WORKERS=2 UWSGI_THREADS=4

and the entrypoint runs gunicorn against the WSGI application:

CMD ["python", "-m", "gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000"]

One comment explains a decision worth copying: collectstatic was moved to runtime, into the pre-deploy script, so that the build does not require a database, because django-prometheus with the export migrations setting connects to the database at startup.

The gap is the licence. The repository's top level does not include a licence file, and no licence is declared for the project, which for software intended to run a school's admissions and fee processing is not a formality to be sorted out later. The last push was on 2026-10-19 and there are no tagged releases, so the checkout is the distribution channel, and any fork inherits the same uncertainty.

Editorial conclusion

Django-School-Management suits a school or training institute that needs an admissions and fees workflow running quickly, and the parts that work are worth reading closely, because the application code, the fixtures, the Braintree sandbox path and the performance stack are all in one place. It is the wrong choice if you need to know the licensing terms, since no licence file appears at the top level of the repository and none is declared, which is a real obstacle for a commercial deployment. Before you build on it, read the requirements file, because it pins a large set of packages at exact versions, and check the fixture load order, since the students fixtures assume the teachers and academics ones are already in place. The last push was on 2026-10-19 and the repository publishes no tagged releases, so the checkout is the only distribution channel.

Frequently asked questions

Official sources

1. Issues
2. README
3. TareqMonwer/Django-School-Management on GitHub