How do you self-host a CRM with Docker and PostgreSQL?
To self-host a CRM, you need a Linux server with Docker and Docker Compose, a domain with a TLS reverse proxy, and a PostgreSQL database with persistent storage. You start the stack with Compose, let migrations run before the app, and back up the database together with the file storage. Updates run the migrations first.
What does a self-hosted CRM need?
- A Linux server with Docker and Docker Compose
- A domain and a reverse proxy with TLS
- PostgreSQL with a persistent volume
- Persistent storage for attachments
- Outbound access only for what you enable, such as email or a model provider
Docker Compose defines and runs a multi-container application from one file, which is why most self-hosted business software ships that way [1]. One file, one command, and the whole stack comes up in the right order.
What runs in a self-hosted CRM stack?
| Service | Job |
|---|---|
| db | PostgreSQL with a persistent volume, reachable only inside the stack |
| auth | Sign-in |
| rest and gateway | Internal API layer and gateway |
| storage | File storage for attachments, with a persistent volume |
| migrate | One-shot database migrations |
| app | The CRM application and its background worker |
| cron | Scheduled calls for recurring jobs |
This is the Sigma CRM stack. Only the app is reachable from outside, through your proxy, and the database has no published port at all.
How do you back up a self-hosted CRM?
Back up the database and the files together, because the rows point to the files. For PostgreSQL that's pg_dump, which makes a consistent backup even while the database is being used [2]. The storage volume goes next to it, from the same point in time.
And test the restore. A backup that was never restored is a hope, and the day you need it is the worst day to find out it's incomplete.
How do you update a self-hosted CRM safely?
Run the database migrations in their own step before the new app starts, and stop the update if a migration fails. Then the old version keeps running and nothing is half-migrated. Decide the update rhythm yourself, that's one of the reasons to self-host in the first place.
Self-hosted, on-premise or cloud: which fits your team?
If nobody in your company wants to run servers, self-hosting is the wrong choice, no matter what it saves on paper. At JadenX we offer Sigma CRM self-hosted under the Enterprise license, which is perpetual, and in our cloud as a subscription with credits. Our own instance runs as a Docker Compose resource, every image passes formatting, linting, type checks and tests before it can ship, and building the images needs about 3 GB of free memory. The business side of the decision is on on-premise or cloud, the technical one on self-hosted CRM.
Frequently asked questions
Is Sigma CRM open source?
No. It is commercial software. Self-hosting runs under the Enterprise perpetual license.
Which database does a self-hosted Sigma CRM use?
PostgreSQL, as its own container with a persistent volume and no published port.
Can a self-hosted CRM run without internet access?
The CRM itself runs inside your network. Email sending, enrichment or a cloud model provider need outbound access to those services.
Does the MCP server work self-hosted?
Yes. Claude Code needs network access to the endpoint, the Claude app needs it reachable over https.
References
- Docker, "Docker Compose", Docker Docs, 2025. https://docs.docker.com/compose/
- PostgreSQL Global Development Group, "pg_dump", PostgreSQL Documentation, 2025. https://www.postgresql.org/docs/current/app-pgdump.html
About this article: I work with a set of AI agents that research sources and turn my notes and the Sigma CRM documentation into a draft. The product facts come from our own documentation and code. The opinions are mine.
If your IT team is thinking about self-hosting a CRM, talk to me at JadenX and we'll go through your infrastructure together.