Self-Hosted CRM with Docker and PostgreSQL

Customermates is a self-hosted CRM you can run as two Docker Compose services: the application and PostgreSQL 16. It is a good fit when your team wants to operate its CRM infrastructure and use an open-source core. It is not the self-hosted edition of every Customermates Cloud feature.

A self-hosted CRM runs on servers you control instead of the vendor's cloud: you decide where the application and database live, and you take on updates, backups and security. Whether the code is open source is a separate question about licence rights, covered in the open-source CRM guide. This page covers the operational side for Customermates.

At a glance

Runs on your infrastructure

The Customermates application and PostgreSQL 16 run as two services in the tracked Docker Compose deployment.

Included product surface

Core CRM records, custom fields and views, REST, webhooks and MCP with the Starter feature set.

You operate

Network access, TLS, updates, backups, restore tests, monitoring and every configured external provider.

Cloud-only boundary

Connected messaging, the unified inbox, connected calendar, hosted Mate and hosted AI credits stay outside self-hosting.

Deployment

Docker Compose

Database

PostgreSQL 16

CRM core

Five record families

Interfaces

REST, webhooks and MCP

Entitlements

Starter baseline

What runs in your infrastructure?

The tracked deployment contains:

• the Customermates application image;
• a PostgreSQL 16 database;
• the core records for contacts, organizations, deals, services and tasks; and
• REST, webhooks and MCP access for external AI clients.

The Compose file does not bundle n8n, an AI model, an email-delivery provider or a separate worker. Authentication emails still require the configured external delivery service. If you connect any provider, you operate that integration separately and should review the data it receives.

What is included and excluded?

The unified CRM inbox is a managed-cloud feature from Pro upward. Self-hosting remains focused on the CRM's open-source core and external MCP clients.

Open-source and commercial code boundaries

First-party material outside ee/ is licensed under AGPL-3.0-only. Inside ee/, material is commercially licensed except for the client-side images, fonts, CSS and JavaScript material identified as AGPL Client Material in Section 6 of ee/LICENSE.md. Review both licenses before modifying, redistributing or operating the software for your use case.

That distinction matters when comparing an open-source CRM: a public repository alone does not tell you which code you may use under which terms. If you are weighing other self-hostable projects, the EspoCRM and Twenty comparisons show how their deployment and licence boundaries differ.

What control does self-hosting provide?

You choose where the application and PostgreSQL run and how you configure network access, backups, retention and updates. That is meaningful infrastructure control, but it is not an automatic compliance, security or air-gap guarantee.

Connected services remain separate processing boundaries. OAuth providers, SMTP, monitoring, workflow tools and external AI providers receive whatever your configuration sends to them. A self-hosted installation sends no Sentry data unless you configure a Sentry DSN, but that narrow default is not a blanket no-telemetry promise.

Self-hosted or managed cloud?

Records move between installations or from another CRM as XLSX workbooks, one record type at a time and within row limits, or through the REST API. Attachments and a complete account transfer are not part of that path, so plan a larger move as a migration project you validate.

How to evaluate the deployment

1. Inspect the exact deployment

   Read the self-hosting guide and review the current Compose file in the repository.

2. Check the edition boundary

   Confirm that the Starter feature set covers the records, views and interfaces your workflow needs.

3. Map external services

   List every SMTP, OAuth, monitoring, workflow or AI provider you plan to configure and the data each one receives.

4. Design operations

   Define backups, tested restoration, upgrades, TLS, monitoring and access control for your environment.

5. Test without customer data

   Run the complete workflow in a non-production environment before the system handles real records.

Frequently asked questions