VisionQuantech CRM Platform: A Self-Hostable, Multi-Tenant CRM Foundation (Open Source)

TL;DR: An open-source CRM foundation you can self-host: an Express/TypeScript API with security middleware and API-key auth, a Next.js 15 frontend, and a docker-compose stack wiring PostgreSQL 15, Redis 7, Kafka (via RedPanda), MinIO and Elasticsearch — plus Kubernetes manifests, CI/CD workflows and deployment scripts. The README is unusually honest about what's real versus roadmap: the contacts API currently runs on an in-memory demo store, with Postgres as the documented production swap.

The problem: hosted CRMs rent you your own data

For a small or mid-sized team, a hosted CRM means per-seat pricing that grows with headcount, data sitting on someone else's infrastructure, and a feature roadmap you don't control. Self-hosting alternatives exist, but most are either single-user tools stretched past their design or enterprise platforms with enterprise complexity. The gap is a CRM foundation — multi-tenant from the start, API-first, with the infrastructure (queues, search, event bus, object storage) already wired so a team can build their sales process on top instead of assembling plumbing for a month.

That's the stated aim of this repository: "designed for self-hosting, customization, and commercial product development." The notable part is the second half of that sentence, which most READMEs omit: "not as a claim that every enterprise capability is already complete or production-certified." Honest scoping, in writing, in the repo.

Architecture: the full stack, containerised

The system separates into the classic three tiers — user-facing frontend, API, and asynchronous workers — with PostgreSQL as the system of record, Redis for caching and queues, and Kafka for event distribution as workloads grow:

Next.js 15 frontend ──► Express/TypeScript API
                              │         ┌──────────┐
                              ├────────►│ Postgres │  system of record
                              ├────────►│  Redis   │  cache + queues
                              └────────►│Event bus │  Kafka / RedPanda
                                           │
                                     Background workers
                                  (imports · dispatch · analytics)

The docker-compose.yml I read makes this concrete rather than aspirational — six services, each with healthchecks:

• PostgreSQL 15 (Alpine) with init scripts mounted (01-schema.sql, 02-seed.sql), persistent volume, and a pg_isready healthcheck.
• Redis 7 (Alpine) with append-only persistence and a redis-cli ping healthcheck.
• Kafka via RedPanda in dev-container mode — Kafka-compatible event streaming without the ZooKeeper-era operational weight.
• MinIO — S3-compatible object storage for attachments and documents.
• Elasticsearch 8.11 — single-node, for the search layer the CRM's "customer 360" needs.

Kubernetes manifests (infrastructure/kubernetes/backend.yaml, secrets.yaml) and Terraform documentation paths extend the same topology to clusters, and .github/workflows/ carries ci-cd.yml and deploy.yml alongside deploy.ps1 / deploy-backend.ps1 / deploy-frontend.ps1 and a Unix scripts/install.sh. A backend/scripts/smoke.js gives new deployments a quick health check.

Under the hood: the API and the workflow engine

The contacts API — security-first, demo-honest

backend/src/index.js is the running API, and it's the file that best shows the project's character. The security posture is set before any route is defined:

• helmet() for HTTP headers, express.json({ limit: '256kb' }) body cap, and CORS as an explicit allow-list from CORS_ORIGINS — never a wildcard when credentials are involved.
• API-key auth on every non-public endpoint via the x-api-key header. The key resolution code is worth quoting in spirit: a default demo key exists only so a fresh clone boots, and production refuses to boot without an explicitly configured key (process.exit(1) with a [fatal] log). No hardcoded secrets; .env.example documents PORT, API_KEY, CORS_ORIGINS, SEED_DEMO, NODE_ENV.
• Request validation with Joi on the contact payloads.

And then the honest part, stated in the file's own header comment: the store is in-memory — let contacts = [] with an optional SEED_DEMO seeding a few sample contacts. "Production deployments should swap the in-memory store for Postgres (DATABASE_URL) — see README." This is a demo-grade API wearing its status openly, and the swap path is documented rather than hidden.

The workflow engine

backend/services/workflow.ts defines the automation layer as typed interfaces: workflows with trigger_type of lead_created | deal_stage_changed | contact_updated | scheduled | manual; conditions (equals / not_equals / contains / greater_than / less_than / in / not_in, combinable with AND/OR logic); and actions — send_email, create_task, update_field, send_notification, webhook, wait — each with its own config shape and optional delay_minutes. The service imports pg, a Redis manager, a Kafka manager, and an email service, which tells you where the engine is headed: event-driven automation evaluated against Postgres state, dispatched through queues.

Around it sit the contact_service.ts and email_service.ts modules, the docs/ARCHITECTURE.md and docs/SUMMARY.md design documents, and DEPLOYMENT.md for operations. The declared capability list — lead capture/scoring/routing and bulk import, customer-360 contact management, custom pipelines with stage transitions, activity tracking, workflow automation, analytics and funnels, organisation-aware multi-tenancy with RBAC, audit logging, Redis caching/queues, Kafka-oriented async processing — is the roadmap-shaped part of the repo; the code delivers the foundation and the honest demo, not all of it.

Code-level specifics worth noting

• The security defaults are the real product: production refusing to boot without an API key, CORS as an explicit allow-list, Helmet headers, a 256KB JSON body cap, and Joi validation on payloads — this is the checklist a security review asks for, already implemented in a demo-grade API.
• Smoke tests ship with the repo: backend/scripts/smoke.js gives every new deployment a quick health verification — the kind of file that only exists when someone has actually deployed the thing more than once.
• Deployment is multi-target from day one: docker-compose for single-host, Kubernetes manifests for clusters, Terraform documentation paths for infrastructure-as-code, plus CI/CD workflows and both PowerShell and Unix install scripts. Whoever builds on this doesn't start from "how do I deploy it."
• The workflow engine's imports tell the roadmap: workflow.ts pulls in pg, a Redis manager, a Kafka manager, and an email service in the same file — the evaluation-against-Postgres, dispatch-through-queues architecture is designed, even where the execution wiring is still being completed.
• Docs are part of the deliverable: docs/ARCHITECTURE.md, docs/SUMMARY.md, and DEPLOYMENT.md mean the design rationale and the operations runbook travel with the code — critical for a foundation other teams are meant to build on.

How to run it

1. Clone and configure: git clone https://github.com/Shivay00001/crm-platform.git, then cp .env.example .env and set a real API_KEY (anything beyond a local demo).
2. Bring up the stack: docker compose -f infrastructure/docker/docker-compose.yml up — Postgres, Redis, RedPanda, MinIO and Elasticsearch come up with healthchecks; the schema and seed scripts initialise the database.
3. Start the API and frontend: the backend boots on port 8004 by default; GET /health is the liveness probe, everything else needs the x-api-key header. Run backend/scripts/smoke.js to verify the deployment.
4. For production: set NODE_ENV=production (the boot checks then enforce the API key), wire DATABASE_URL to Postgres to replace the demo store, and follow DEPLOYMENT.md plus the Kubernetes manifests for cluster deployment.

Honest status and roadmap

Partial — a working foundation, not a finished product. What's real: the containerised infrastructure (all six services, healthchecks, init scripts), the security middleware and API-key discipline in the backend, the workflow engine's typed design, the deployment automation (Compose, Kubernetes, CI/CD, install scripts), and the docs. What's demo-grade: the contacts API's in-memory store, explicitly marked for the Postgres swap. What's roadmap: the full capability list (lead scoring, pipelines UI, analytics/funnels, multi-tenant RBAC enforcement across every surface) and the "production-readiness assessment" and "monetization options" sections the README itself contains — the repo knows what it still has to become.

The license is a custom VisionQuantech license (commercial license available, per the repo description) — read LICENSE before building a business on it. Sensible next steps from the code's shape: the Postgres-backed contact store, migrations wired into the Compose init path, the workflow engine's condition evaluator executed against real events, and frontend routes for pipelines and analytics.

The bottom line

Most "CRM platform" repos are either a UI mock or an undocumented API. This one is rarer: honest about its demo-grade store, serious about its security defaults, and complete where it matters most at foundation stage — the containerised data plane, the deployment paths, and the workflow engine's design. If you're evaluating a self-hosted CRM base to build on, the README's production-readiness assessment is the first thing to read; it's the document that tells you the author knows exactly what's left.

Repository: github.com/Shivay00001/crm-platform · Want a CRM or internal platform built for your team? VisionQuantech designs and deploys custom CRM, automation and AI-agent platforms. Contact: [email protected]