django-job-portal is a full job board, not a snippet

The scope is a whole portal, employers and candidates both

Django Job Portal is described as an open source online job portal, and the screenshot list in the README shows how much of a product it actually is. There is a home page, a companies page, a resume template page with two views, a form for an employer adding a new position, a job details page and a Swagger API page. The used tech stack is listed as two entries, Django and Sqlite, and the repository layout confirms the shape of the thing. There are `accounts/`, `jobs/`, `categories/`, `tags/`, `resume_cv/`, `jobsapp/`, `utils/` and `tests/` application directories alongside `templates/`, `static/`, `media/`, `locale/` and a `deployment/` folder. So this is not a job board model you drop into a site. It is a working application with two kinds of user, employers who post positions and candidates who build a resume, plus the admin surface behind them. A live demo is published at a subdomain, and the project takes part in Hacktoberfest, which explains the contribution and pull request traffic around a project of this shape.

An API surface that spans REST, GraphQL and Swagger

The API story is broader than most Django starters offer, and it is the part most likely to matter if you plan to build a separate frontend or a mobile client on top. The pinned requirements include djangorestframework at 3.15.2, drf-yasg for the Swagger schema, simplejwt for token authentication and django-oauth-toolkit, and there is a GraphQL stack too: graphene, graphene-django, graphene-file-upload and graphql-relay. Search infrastructure is there too, with django-elasticsearch-dsl, elasticsearch and elasticsearch-dsl in the pinned versions, which is the kind of choice that suggests full-text search over jobs is a first-class feature rather than an afterthought with a LIKE query. The pinned list also includes django-braces for class-based view mixins, django-cors-headers, django-environ for configuration, django-prometheus for metrics export, and Pillow for image handling on resumes. A README section devoted to a testing series for Django REST Framework, with worked examples of API test cases, is a good sign about how much of the codebase the author expects to be extended.

Running it locally, from the virtualenv to the demo data

The local setup is a five step sequence, and it is worth following exactly because the `.env` file is not optional. First a virtual environment, either with `virtualenv venv` or with `python3.11 -m venv venv`, then activation with `source venv/bin/activate`, then the packages with `pip install -r requirements.txt`, then the environment file with `cp .env.dev.sample .env`, and finally adding a GitHub client ID and client secret in that `.env` file. The GitHub credential requirement is worth pausing on, because the project uses social login, and the OAuth packages in the requirements, django-oauth-toolkit and django-rest-framework-social-oauth2, are the reason. Once the environment exists, the run steps are a collectstatic, a migrate, an optional fixture load and the server.

    python manage.py collectstatic

The container image in the repository does the install work in two steps, copying the requirements file and installing from it.

COPY requirements.txt requirements.txt

# RUN python -m pip install --upgrade pip
RUN pip install -r requirements.txt

The web service in the compose file is the one that serves the portal.

  web:
    restart: always
    build: .
    environment:
      ENABLE_PROMETHEUS: 1
    command: ./entrypoint.sh

The fixture command is generic in the README, with `app_name` and `model_name` as placeholders for the app and model you want to seed, and the reverse operation for dumping data back out into a fixture file is documented alongside it. The README also notes that collectstatic is unnecessary when debug is True, which is the normal development case.

Default admin credentials are published in the README

The README states the default Django admin credentials directly, as an email address of [email protected] with the password admin. This is normal for a development project and completely unacceptable for a deployment, and it is the first thing to change when you stand this up. The two `Dockerfile` and `Dockerfile.prod` files, the `entrypoint.sh` and `entrypoint.prod.sh` scripts, the `Procfile` and `Procfile.windows` files and the `docker-compose.yml` and `docker-compose.prod.yml` files all point to a project that expects to be deployed rather than only run locally, and a deployment with a published admin password is the kind of thing that gets picked up by a scanner within hours. The presence of a `.env.dev.sample` file gives you the shape of the configuration you need to replace, and `django-environ` is what reads it. The other detail to notice in that file listing is `db.sqlite3` at the repository root, which is a development artefact you should not carry into production even though the project ships with it.

The observability stack is part of the repository

The docker-compose file is not a minimal app container, and this is the most unusual thing about the project. It defines five services. Prometheus is configured from a `provisioning/prometheus` directory mounted at `/etc/prometheus` and publishes port 9090. Alertmanager publishes 9093. Grafana runs on 3000 with a datasources directory and a dashboards directory mounted from `provisioning/grafana`. A node-exporter publishes 9100, described in the file as an example of an additional service as an exporter. And the web service itself builds from the Dockerfile, runs `./entrypoint.sh`, mounts the working directory and the SQLite file, and publishes 8000. The `web` service also sets `ENABLE_PROMETHEUS: 1` in its environment, which ties the Django app to the metrics side, consistent with django-prometheus being in the pinned dependencies. The `provisioning/` directory at the repository root is what makes this work. For a job board this is unusual ambition: most starters of this shape ship with nothing at all.

Where the SQLite default and the pinned dependency list collide

The requirements file is fully pinned, which is good for reproducibility and bad for maintenance. Django is pinned at 5.1.2, djangorestframework at 3.15.2, and the list runs to well over a hundred entries including Pillow, cryptography, gunicorn, requests and psycopg2-binary. Two consequences follow. The first is that the stated stack of Django and Sqlite is the development story, because psycopg2-binary in the requirements means a PostgreSQL path is available and probably expected in production, and the docker-compose file mounts the SQLite file directly, so a production deployment through that file is running on SQLite. The second is the maintenance cost of a long pinned list in a project with no GitHub releases, no changelog and a last push on 2026-09-27. When a dependency in that list carries a security advisory, there is no release note telling you which version fixed it, and Django itself moves on its own schedule. The `Makefile`, `pyproject.toml`, `.pre-commit-config.yaml` and `Jenkinsfile` at the repository root show a real toolchain, with black and isort configured with a line length of 120 in the pyproject file, but the operational surface around the application is thin.

Editorial conclusion

Adopt django-job-portal if you want a complete, self-hosted job board with employer and candidate flows already built, including a Swagger API and an existing deployment setup. Skip it if you only need a job listing model, because the account system, the resume builder, the search, the tags and the observability stack are all part of the package and are not separable in a documented way. Before you commit, read the default admin credentials in the README, plan to change them, and check that your hosting target can run the PostgreSQL path implied by psycopg2 in the requirements rather than the SQLite default.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. manjurulhoque/django-job-portal on GitHub
4. README