Self-Hosted CRM

Marketing & Sales

A customer relationship management system: it handles leads, client companies, contacts, deals, support tickets, to-dos and invoices, and comes with a script that loads demo data. You bring it up on your own machine with Docker Compose, the keys and database passwords are generated at random by a script, and sign-in goes through a link sent to an email address. Derived from a frozen snapshot of an open-source project under the MIT licence; the delivery adds an orchestration file (backend, background worker, front end, database and Redis), a Dockerfile that builds the images from source, scripts that generate the keys and load the demo data, and a quick-start guide in Traditional Chinese.

Subscribe & download See how to start

SubscriptionUS$49 per month

Last run2026-11-02

In practice

Readiness4 / 5

What you need

Few changes needed4 / 5

Who it is for

Individuals and small teams who want to manage leads, contacts and deals on their own machine.

How to start

$ sh scripts/quickstart/init-env.sh
$ docker compose up -d --build
$ sh scripts/quickstart/seed-demo.sh [email protected]

Browse the files

Files in the product repository at the pinned commit. A few house files are left out of the zip.

File overview2,000+ paths

▸backend1014

.env.example
.python-version
README.md
accounts/
automation/
business_hours/
cases/
common/
conftest.py
contacts/
…

▸docker5

backend/
nginx/
postgres/

▸docs65

api/
architecture/
contributing/
design/
getting-started/
index.md
integrations/
mobile/
reference/
self-hosting/

▸frontend352

.dockerignore
.env.example
.gitignore
.npmrc
.prettierignore
.prettierrc
Dockerfile
README.md
components.json
eslint.config.js
…

▸mobile531

.gitignore
.metadata
CLAUDE.md
DESIGN_SYSTEM.md
FIREBASE_SETUP.md
README.md
analysis_options.yaml
android/
assets/
devtools_options.yaml
…

▸scripts3

quickstart/

▫ATTRIBUTION.md

▫CLAUDE.md

▫CONTRIBUTING.md

▫DESIGN_SYSTEM.md

▫Dockerfile

▫LICENSE

▫LICENSE-99LL.md

▫MANIFEST.in

▫PRODUCT.md

▫QUICKSTART.md

▫README.md

▫RLS_SETUP.md

▫SECURITY.md

▫SECURITY.upstream.md

▫delivery-manifest.txt

▫docker-compose.yml

▫mkdocs.yml

▫schema.yml

▫Config and hidden files 12

Latest passing run

Clone → Checkout → Toolchain → Build images → Crm magic link login

Pre-purchase Disclosure

What you are buying

A self-hosted customer relationship management system: it handles leads, client companies, contacts, deals, support tickets, to-dos and invoices. After running the key generation script you bring it up with Docker Compose, then run a script that creates the organisation and the demo data.

Derived from an open-source project under the MIT licence, and not the original project itself. Our work: a Dockerfile that builds the images from source, an orchestration file, scripts that generate the keys and load the demo data, a script that fetches the sign-in link and a quick-start guide in Traditional Chinese.

Delivery is a frozen snapshot: one zip, taken from the product repository at revision 007410a.

Known limitations

The services are bound to ports 8000 and 5181 of the local machine only; TLS and a reverse proxy are yours to bring
The sign-in page is in English
Sign-in is by emailed link only, and Google sign-in is not set up
The sign-in mail is only printed in the log by default and is not sent; sending it needs your own SMTP service
The sign-in link is valid for ten minutes and can be used once
The organisation and the demo data are created by a separate script
The web fonts are loaded from Google Fonts, so the browser connects to Google when a page opens
The privacy policy and terms links on the sign-in page point at the upstream site and do not apply to a self-hosted copy
The database password is written when the database is first created, and changing only .env leaves the backend unable to connect
The data lives in Docker named volumes, and docker compose down -v deletes all data and uploaded files
The first start builds the images from source, fetching from registries, apt and package repositories during that time
Pinned to the delivered snapshot; it does not follow upstream.

The liability cap, the scope of what is promised and the statutory floor are governed by the Terms of Service.

Vetting record

Everything below was checked against the pinned commit e9dc374. Every verdict carries its full reasoning, an evidence link and the checker; failures are published, not hidden — do not take our word for it, verify it yourself.

5 PASS0 WARN0 FAIL

Source ReviewPASS

Execution surface of the delivery reviewed item by item. Our own additions were read: docker-compose.yml (the published ports are bound to 127.0.0.1 only; it refuses to start when SECRET_KEY or either database password is missing; the database and Redis publish no ports; by default mail is only printed to the log and not sent), docker/backend/entrypoint.selfhost.sh (applies the database structure and starts gunicorn, and creates no default administrator with a fixed password), backend/crm/selfhost_settings.py (refuses to start when DEBUG is on, a development default key is in use, cross-origin access is open to all or the app connects as the postgres superuser), docker/postgres/init-app-role.sh (creates a non-superuser application role, because row-level security does not apply to a superuser), docker/nginx/default.conf (only forwards and adds the protocol header, and does not terminate HTTPS) and the three scripts under scripts/quickstart (openssl generates random values, .env is mode 600 and an existing one is not changed; the demo users get random passwords; the link script reads only the local log). The upstream Python and front-end sources were not read file by file; the basis is the MIT licence and container isolation.

Script SafetyPASS

The scripts on the buyer’s delivery path were each inspected: the three scripts under scripts/quickstart and the backend entry script are ours (read); the build goes through Dockerfile and frontend/Dockerfile (read: system packages come from apt, uv and pnpm install from lock files, with no download piped straight into a shell). At start-up the backend runs the database migrations and gathers the static files, and the background worker and the scheduler each run in their own container.

RecencyPASS

This product is a frozen snapshot and does not follow upstream: the upstream source is pinned to the main-line revision taken on the day the product repository was created (see the evidence link), and the product repository is that snapshot plus our own commits.

LicensePASS

SPDX:LicenseRef-99LL-Product

Upstream LICENSE was checked word for word (the evidence link points at the file itself at the pinned version and matches the copy inside the product repository): the standard MIT text, copyright holders MicroPyramid and RunCode Inc. It allows commercial use, modification, derivative works, redistribution and sale; the duty is to keep the copyright notice and licence text (LICENSE and ATTRIBUTION.md ship in the zip); upstream has no NOTICE file. The decision does not rest on GitHub’s licence field. For the product as a whole the 99LL product licence template is attached: upstream’s LICENSE is kept as it is and LICENSE-99LL.md is added as the sale and liability terms for the part we built, with spdx recorded as LicenseRef-99LL-Product.

Dependency LicensesPASS

This records the declared side, not a scan result: the Python dependencies are declared in backend/pyproject.toml and locked by uv.lock, the front end is declared in package.json and locked by pnpm-lock.yaml, and the packages themselves are fetched from their own repositories when the buyer builds; the base image, the database, Redis and nginx come from a registry and the system packages from apt. These dependency trees were not scanned package by package for licences. Upstream has no submodule and no third-party dataset was copied in (see ATTRIBUTION.md).