Django-CRM (BottleCRM): Free Self-Hosted CRM on Django and SvelteKit

What Django-CRM covers and who runs it

The project's README describes it as BottleCRM, a name used on the marketing site at bottlecrm.io. The GitHub repository is Django-CRM/Django-CRM. Both names refer to the same codebase.

The CRM module covers the full customer lifecycle as described in the README: leads, accounts, contacts, opportunities, support tickets, tasks, and invoices. The helpdesk component includes SLA timers, approvals, escalations, macros, and a knowledge base. These are native features of the application, not third-party integrations.

Three client surfaces share one Django backend: a SvelteKit web application, a Flutter app for iOS and Android, and a REST API with an OpenAPI schema that ships with the repository. Engineers who need to automate CRM operations can point any OpenAI-compatible agent or scripting tool at the API using personal access tokens.

The multi-tenancy implementation uses PostgreSQL Row-Level Security (RLS), which enforces tenant data isolation in the database engine rather than in application code. This means a misconfiguration in business logic cannot leak data between tenants if the RLS policy is correctly in place.

Getting started with Docker Compose

The README's quick start is three commands:

git clone https://github.com/django-crm/Django-CRM.git
cd Django-CRM
docker compose up --build

After the build completes, the frontend is available at http://localhost:5181 and the backend API, along with a Swagger UI, at http://localhost:8000/swagger-ui/.

The docker-compose.yml defines five application services: backend (port 8000), a frontend service, a celery-worker for background tasks, a celery-beat for scheduled tasks, and a supporting database. It also defines PostgreSQL 16 (port 5432) and Redis 7 (port 6379) as infrastructure services. A PostgreSQL initialization script at docker/postgres/init-rls-user.sql runs at database startup to set up the RLS user.

The Dockerfile builds the backend image from python:3.12-slim-bookworm and uses uv for Python dependency installation. The image installs system libraries for WeasyPrint (cairo, pango, and gdk-pixbuf), which is used for PDF generation. Environment variables come from an .env.docker file, with an optional .env.docker.local file for local overrides that is git-ignored.

The stack in detail: Django 6, Svelte 5, Flutter

The README explicitly names the stack as Django 6 and DRF on the backend, Svelte 5 on the web frontend, and Flutter for mobile. The Python base image in the Dockerfile is Python 3.12. The backend dependency files are at backend/pyproject.toml and backend/uv.lock.

The REST API ships with a schema.yml file at the repository root, which is an OpenAPI schema describing the available endpoints. The README notes that an agent can discover endpoints from this schema using a personal access token that inherits the user's role and permissions.

The celery-worker service runs Celery against the crm application. This is the standard Django pattern for background task processing. Celery-beat handles periodic scheduled tasks. Redis serves as the message broker and task queue backend. Both Celery services and the backend wait for the PostgreSQL and Redis health checks to pass before starting.

The frontend directory contains the SvelteKit application, and the mobile directory contains the Flutter application. These are separate from the backend and built or deployed independently.

Multi-tenancy via PostgreSQL Row-Level Security

The multi-tenant architecture is a distinguishing technical choice. Most self-hosted CRMs that support multiple organizations do so by filtering data at the application layer, which means a bug in the query filter can expose rows from the wrong tenant. BottleCRM uses PostgreSQL Row-Level Security, which enforces the filter inside the database engine.

The RLS user is initialized by the docker/postgres/init-rls-user.sql script that runs at database container startup. The RLS_SETUP.md file at the repository root documents the setup process. The README notes that this design allows the same deployment to serve a single startup or hundreds of tenants. Running it for a SaaS product with multiple customer organizations is a documented use case.

The practical implication is that the PostgreSQL version matters. The docker-compose.yml pins PostgreSQL 16 with the postgres:16-alpine image. Running on a different version requires verifying that RLS policies behave identically, since RLS implementation details can differ between major PostgreSQL versions. The PostgreSQL service is health-checked with pg_isready before the backend or Celery workers start.

Limitations and operational requirements

The Docker Compose stack requires running PostgreSQL, Redis, a backend service, a Celery worker, a Celery beat scheduler, and optionally a frontend service. This is a reasonable production deployment for a small to mid-size team with an operations engineer, but it is more moving parts than a single-process CRM tool that embeds its queue and database.

The WeasyPrint dependency, used for PDF generation of invoices, requires system-level libraries. The Dockerfile installs libcairo2, libpango-1.0-0, libpangocairo-1.0-0, libgdk-pixbuf2.0-0, and libffi-dev. If you build the backend image outside Docker or deploy to a bare server, those libraries must be installed manually.

The mobile Flutter app is part of the repository but the README does not document how to build or distribute it. Teams that specifically need the mobile client will need to follow standard Flutter build procedures, which are not covered in the available documentation references.

There is no explicit guidance in the README about migrating existing CRM data into Django-CRM. The marketing site mentions a migration path from Salesforce and HubSpot, but the technical documentation for that process is external to the repository.

Comparison with Odoo's CRM module

Odoo is a modular ERP and CRM platform written in Python. Its CRM module covers leads, pipelines, and customer management, and it is available under the LGPL license for the community edition. Odoo's architecture is a single Python application with a JavaScript frontend and an ORM that handles multi-company setups through its own layer.

Django-CRM uses a different approach: it exposes a REST API rather than Odoo's RPC-based interface, uses SvelteKit as a separate frontend application rather than Odoo's bundled JavaScript framework, and enforces multi-tenancy through PostgreSQL RLS rather than application-layer company filtering. The REST API and the OpenAPI schema make Django-CRM easier to integrate with custom scripts and AI agents. Odoo's community edition has a larger catalog of modules for ERP functions beyond CRM; Django-CRM is focused on the CRM and helpdesk scope and does not provide ERP functionality.

Maintenance and license

The repository is not archived. The last push was on 2026-09-27. The most recent release is v1.14.1, also from 2026-09-27, which is one day before the date of this writing. The project is under active development.

The license is MIT. There are no usage restrictions, user caps, or feature paywalls. The README states that managed hosting is available from MicroPyramid, the project sponsor, but the self-hosted version has no license limitation on the number of users or records.

Commercial support is available through micropyramid.com.

Editorial conclusion

Django-CRM suits teams that want a self-hosted CRM with a recognizable Python and JavaScript stack, no per-seat pricing, and the option to run it for multiple tenants on a single deployment. It is a poor fit for organizations without the engineering capacity to operate a multi-service Docker stack, handle PostgreSQL Row-Level Security configuration, or manage Celery workers. Before deploying to production, read RLS_SETUP.md to understand how tenant isolation is set up, verify that the PostgreSQL RLS user is correctly configured from docker/postgres/init-rls-user.sql, and confirm that your environment can run the Celery worker and Celery beat services alongside the main backend.

Frequently asked questions

Official sources

1. Django-CRM/Django-CRM on GitHub
2. License: MIT
3. Project website
4. README
5. Releases