DEV Community: Horilla

Horilla CRM: A Free & Open-Source Django CRM for Modern Businesses in 2026

Horilla — Thu, 07 May 2026 07:33:03 +0000

If you've spent any time searching for an open-source CRM, you've probably hit the same wall most teams hit: the popular options are either bloated, expensive at scale, locked behind paid editions, or built on aging PHP stacks that are painful to extend.

In this post, I want to introduce you to Horilla CRM — a free, self-hosted, open-source CRM built with Django 6 and Python 3.13. It's designed for teams who want full control over their customer data, deep customization, and a modern developer experience — without paying per seat.

Note: Horilla also ships a separate HRMS product in its own repository. This article is focused on Horilla CRM specifically. If you need HR features, you can install the HRMS repo alongside the CRM — they're designed to live in the same ecosystem but are deployed independently.

Let's dig into what makes it different, what it can do, and how it stacks up against the usual suspects like SuiteCRM, EspoCRM, and Vtiger.

Why Another Open-Source CRM?

Most "free CRMs" today fall into one of three buckets:

Freemium SaaS — free until you hit 3 users, 1,000 contacts, or any feature you actually need.
Legacy PHP CRMs — SuiteCRM, Vtiger, EspoCRM. Mature, but dated stacks and clunky extension models.
DIY Django starters — GitHub projects with 200 stars, a half-finished pipeline, and no docs.

Horilla CRM sits in a different spot. It's a production-grade Django CRM with a real plugin architecture, multi-tenancy baked in, and a modern HTMX-driven frontend — which is rare in the open-source world.

If you're building for a small business, an agency managing multiple clients, or a startup that wants to self-host customer data for compliance reasons, this is worth a look.

What Horilla CRM Actually Includes

Here's the honest feature list — not marketing fluff:

Sales & Pipeline

Leads with custom scoring rules, criteria, and conditions
Opportunities with configurable stages, probability, and forecasting
Accounts & Contacts with relationship tracking
Pipeline visualization powered by ECharts
Sales cadences — scheduled outreach sequences (email, call, task steps)

Marketing

Campaigns with member tracking and metrics
Email integration via the built-in mail module
Forecasting with chart-based insights

Productivity

Activities — calls, meetings, notes, tasks
Calendar integration
Real-time notifications via Django Channels + WebSockets
Keyboard shortcuts for power users
Duplicate detection and record cloning

Workflow & Automation

5 automation triggers: on_create, on_update, on_create_or_update, on_delete, scheduled
Multi-step approval workflows that plug into any model via ContentType
Review processes for peer/manager feedback
Custom signals for cross-module side effects

Pairs With Horilla HRMS (Separate Install)

HR features (recruitment, employee management, payroll, etc.) live in the separate Horilla HRMS repository
You can install both side-by-side if you need a unified HR + CRM stack — useful for agencies and SMBs that don't want two unrelated systems
Each can be deployed independently, so you only run what you need

Developer-Friendly

DRF API for every module
Webhooks
Modular app architecture — drop in new features without touching the core
Multi-tenancy via CompanyFilteredManager
Four-layer permission model: model → field → row → role

The Tech Stack (What You're Actually Running)

Backend:    Python 3.13 + Django 6.0.3
API:        Django REST Framework
Database:   PostgreSQL
Frontend:   HTMX + Tailwind CSS + Flowbite
Charts:     ECharts
Async:      Celery + Redis
Real-time:  Django Channels (WebSockets)
Scheduling: APScheduler (in-process) + Celery Beat

A few things worth calling out:

HTMX over SPA. No React, no Vue. Server-rendered pages with HTMX for dynamic behavior. The result is faster development, simpler debugging, and pages that load in 50ms instead of 3 seconds.
Channels for real-time. Notifications and live updates are pushed via WebSockets, not polled.
PostgreSQL only. The team made the call to skip MySQL/SQLite support in production to avoid the ORM compromises that come with multi-DB.

How It Compares: Horilla CRM vs SuiteCRM vs EspoCRM vs Vtiger

Feature	Horilla CRM	SuiteCRM	EspoCRM	Vtiger CRM
Stack	Django 6 / Python	PHP 8	PHP 8	PHP 7
Frontend	HTMX + Tailwind	Smarty templates	Backbone.js	Smarty
License	Open source	AGPL v3	GPL v3	MPL 2.0
Multi-tenancy	Built-in	Manual	Manual	Paid edition
Real-time	WebSockets	No	No	No
Automations	5 trigger types	Workflow module	Workflow module	Workflow module
Companion HRMS	Yes (separate repo)	No	No	No
Modern stack	Yes	No	Partial	No

The big differentiators for Horilla:

Modern Python/Django stack — easier to hire for, easier to extend.
Optional HRMS companion — install the separate Horilla HRMS repo if you want HR alongside CRM, skip it if you don't.
Real-time by default — WebSockets aren't an afterthought.
Multi-tenant out of the box — CompanyFilteredManager filters every query automatically.

Self-Hosting Horilla CRM

Self-hosting is the whole point. Here's the short version:

# Clone
git clone https://github.com/horilla/horilla-crm.git
cd horilla-crm

# Set up Python environment
python3.13 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

# Configure
cp .env.example .env
# Edit DATABASE_URL, REDIS_URL, SECRET_KEY

# Migrate and run
python manage.py migrate
python manage.py create_horilla_user
python manage.py runserver

For production you'll want:

PostgreSQL 14+
Redis 6+ (for Celery + Channels)
Gunicorn + Uvicorn workers (for ASGI/WebSocket support)
Nginx as a reverse proxy
Celery worker + beat process

A Docker setup is in the repo if you want to skip the manual steps.

What Horilla CRM Is Good For

Be honest about fit. Horilla is a strong choice if you're:

A small or mid-size business that wants to own its customer data
An agency that needs multi-tenant isolation between clients
A team that wants the option to add HRMS later via the separate Horilla HRMS repo
A Django shop that needs a CRM you can actually extend
A regulated industry (healthcare, finance, EU GDPR) where self-hosting matters

It's probably not the right pick if you need:

A turnkey SaaS with zero ops overhead (use HubSpot's free tier)
Deep marketing automation rivaling Marketo
A massive third-party integration marketplace on day one

What's Coming Next

A few things on the roadmap that I'm excited about:

Expanded webhook system
More automation trigger types
AI-assisted lead scoring (already partially landed)
Deeper email threading
Public API documentation portal

The project is actively maintained and the community is open to contributions — the GitHub issues are a good place to start if you want to get involved.

Try It Out

If you've been looking for a free, self-hosted, open-source Django CRM that doesn't feel like 2012, give Horilla CRM a serious look:

GitHub: https://github.com/horilla/horilla-crm
Live Demo: https://crm.demo.horilla.com/
Docs: https://www.horilla.com/crm/

Star it, fork it, file an issue, or send a PR. Open source gets better when more people kick the tires.

TL;DR

Horilla CRM is a free and open-source CRM built with Django 6, designed for self-hosting. It includes leads, pipelines, opportunities, campaigns, sales cadences, and automations — with real-time notifications, multi-tenancy, and a modern HTMX-based frontend. Need HR too? Pair it with the separate Horilla HRMS repo. If you want a CRM you can actually own and extend, it's worth a look.

Have you tried Horilla CRM, SuiteCRM, EspoCRM, or another open-source CRM? Drop your experience in the comments — I'd love to hear what worked and what didn't.

How we cut our Claude Code token costs by 80% — and the open-source tool we built to do it (v1.1.4, 13 commands)

Horilla — Mon, 13 Apr 2026 05:00:02 +0000

Our Claude Code bill was three times what it should have been. For a 9-developer team, that difference was significant enough to make us actually debug it. What we found was embarrassingly simple — and almost certainly affecting your setup too.

The problem: CLAUDE.md loads on every request

Claude Code reads your CLAUDE.md file on every single request. That's by design — it's how the tool loads your project instructions, coding conventions, and context. But here's the part that sneaks up on you: the file is read in full, every time, regardless of what task you're working on.

Our CLAUDE.md had grown to about 10,000 tokens over six months. It contained:

Architecture documentation for 40+ Django apps
Coding standards and patterns for two separate codebases
API references and import paths
Session notes and debugging tips we'd accumulated

Every time a developer asked Claude to fix a typo in a README, the full 10,000-token file was injected into the context. At roughly 60 requests per developer per day, across 9 developers, that's 5.4 million tokens of CLAUDE.md context per month — before writing a single line of code.

Why prompt caching wasn't saving us

Anthropic caches prompts above 1,024 tokens, and it works well — when the prompt is identical between requests. One character of difference and you pay full price.

Our CLAUDE.md had dynamic content: session notes with timestamps, environment-specific paths, and other content that changed between requests. Every request was a cache miss. Every request billed at full input token price.

This is the second thing claudectx analyze catches: dynamic content that breaks caching.

What we built: claudectx v1.1.4

We built claudectx — a CLI that audits and optimizes what Claude Code loads per session. It's now at v1.1.4 with 13 commands across four categories.

npx claudectx analyze

Run this in your project directory right now. No install needed. It outputs:

claudectx analyze — token breakdown
════════════════════════════════════════
CLAUDE.md             7,841 tokens  ████████████████████ 68.1%
Open files            2,840 tokens  ██████               20.6%
Conversation history  1,630 tokens  ███                  11.2%
MCP tool results         14 tokens  ░                     0.1%
────────────────────────────────────────
Total                12,325 tokens

Waste patterns detected (3):
  ⚠  CLAUDE.md: 7,841 tokens — 292% over the 2,000 token recommendation
  ⚠  No .claudeignore file found
  ⚠  CLAUDE.md contains dynamic timestamp — breaks prompt caching
  → Run `claudectx optimize --apply` to fix all 3 issues

The core fix: optimize

claudectx optimize --apply

This does three things automatically:

Splits CLAUDE.md into a lean core + demand-loaded @file sections. Core stays inline (under 2K tokens); large reference sections load only when relevant files are open.
Generates .claudeignore with Node.js, Python, and common binary patterns to stop loading lock files, build artifacts, and assets.
Strips cache-busting content — removes dynamic timestamps and session notes that prevent Anthropic's prompt cache from activating.

Safety: Every file claudectx touches is automatically backed up to ~/.claudectx/backups/. If anything looks wrong, claudectx revert --list shows all backups and claudectx revert --id <id> restores any of them.

On our setup this cut tokens from 18,432 to 3,740 per request (79.7% reduction).

The MCP proxy: symbol-level reads

The less obvious win is claudectx mcp — a local MCP server proxy that intercepts file-read requests and returns symbol-level slices instead of whole files.

When Claude reads a file to find a class definition, it gets the entire file. On a large Django app, that's often 12,000+ tokens for one model. The same information as a symbol-level read (just the class) is typically 800 tokens.

claudectx mcp

Configure Claude Code to use the local MCP server and you get:

smart_read — reads a symbol by name (class, function, method)
search_symbols — finds symbols across the codebase
index_project — builds a local symbol index

Analytics commands

claudectx watch — a live terminal dashboard (Ink/React) showing token burn, cache hit rate, and most-read files as you work.

claudectx compress — distills your session JSONL into a MEMORY.md entry. An 8,000-token session typically compresses to 150–200 tokens. Next session starts lean without losing context.

claudectx report — 7/30-day analytics:

Sessions:          23    Requests:       847
Input tokens:   2,341,200    Cache hits:    51%
Total cost (est.): $4.87   Avg/session:  $0.21
Top waste file:    CLAUDE.md  (12,400 tokens, 847 reads)
→ Run `claudectx drift` to clean up stale sections

`claudectx budget "/.py"`* — estimate token cost before running a task. Shows per-file token counts, cache hit likelihood, total cost, and .claudeignore recommendations. Like git status for your context window.

claudectx drift — scans CLAUDE.md for dead @file references, git-deleted file mentions, and sections with zero reads in the last 30 days. Real cost: you're loading documentation for files that no longer exist.

Teams and multi-assistant support

claudectx teams — per-developer cost attribution for multi-dev teams:

claudectx teams export          # → ~/.claudectx/team-export-{date}.json
claudectx teams aggregate --dir ./reports/  # merge all exports
claudectx teams aggregate --anonymize       # Dev 1, Dev 2...

Each developer exports an anonymized summary of their session data. The lead aggregates them without seeing session content. Know where the budget is going across the team.

claudectx convert --to cursor|copilot|windsurf — exports your CLAUDE.md to other AI assistant formats. Splits sections into .cursor/rules/*.mdc files for Cursor, or .github/copilot-instructions.md for Copilot. One source, every assistant.

claudectx warmup — sends a priming request to Anthropic so your first working request gets a cache hit instead of a full miss. --cron "0 9 * * 1-5" installs as a morning cron job.

claudectx hooks list|add|remove — named hook marketplace. Four built-ins: auto-compress (triggers on file reads), daily-budget (budget check before tool use), slack-digest (session summary to Slack webhook), session-warmup (cache pre-warm on read events).

Real results

After running optimize --apply on our setup:

Metric	Before	After
Tokens per request	18,432	3,740
Cache hit rate	12%	74%
Monthly cost estimate	$87	$17

The 80% figure is real but came from our specific setup — an unusually large CLAUDE.md and a completely unconfigured .claudeignore. If your config is already lean, expect 20–40%. The analyze command will tell you in 30 seconds what your actual baseline is.

Try it

# No install — try immediately
npx claudectx analyze

# Install globally
npm install -g claudectx
# or via Homebrew:
brew tap Horilla/claudectx && brew install claudectx

Website: claudectx.horilla.com
Source (MIT): github.com/Horilla/claudectx

We're the team behind Horilla — an open-source Django HRMS with 40+ apps. This tool came from real pain running Claude Code across a multi-repo, multi-app codebase on a 9-developer team. If you're in a similar situation, we'd love your feedback.

Issues and PRs welcome. If analyze shows something surprising, share it in the comments.