CRM self hosted: rekordy klientów i kolejne kroki na własnych serwerach

Customermates to CRM self hosted, który uruchomisz jako dwie usługi Docker Compose: aplikację i PostgreSQL 16. Pasuje do zespołów, które chcą same prowadzić infrastrukturę swojego CRM i korzystać z rdzenia open source. To nie jest wersja self-hosted wszystkich funkcji Customermates Cloud.

CRM na własnym serwerze działa na maszynach, które kontrolujesz, a nie w chmurze dostawcy: sam decydujesz, gdzie stoją aplikacja i baza danych, i bierzesz na siebie aktualizacje, kopie zapasowe oraz bezpieczeństwo. To, czy kod jest open source, to osobne pytanie o prawa licencyjne, które omawia przewodnik po CRM open source. Ta strona opisuje stronę operacyjną w przypadku Customermates.

Gdzie mieści się follow-up. Self-hosting trzyma rekordy klientów, terminy kolejnych kroków, pulpity i MCP na Twoich własnych serwerach, więc Twój klient AI może je czytać i aktualizować. Nie ma tu skrzynki odbiorczej, która kładzie rozmowy z LinkedIn i e-maila przy kliencie, ani Mate, który pisze szkice odpowiedzi. Jeśli chcesz mieć CRM głównie po to, by follow-up na rozmowach dostawać w postaci szkiców, zacznij od Customermates Cloud; self-hosting pasuje lepiej, gdy ważniejsza jest kontrola nad tym, gdzie działają dane.

Co działa w Twojej infrastrukturze?

Opisane w repozytorium wdrożenie CRM z Dockerem zawiera:

• obraz aplikacji Customermates;
• bazę danych PostgreSQL 16;
• podstawowe rekordy: kontakty, organizacje, szanse sprzedaży, usługi i zadania, a do tego listy, które dodasz sam; oraz
• REST, webhooki i dostęp MCP dla zewnętrznych klientów AI.

Plik Compose nie zawiera n8n, modelu AI, dostawcy wysyłki e-maili ani osobnego workera. E-maile uwierzytelniające nadal wymagają skonfigurowanej zewnętrznej usługi wysyłki. Jeśli podłączysz jakiegokolwiek dostawcę, tę integrację prowadzisz osobno i warto sprawdzić, jakie dane ona otrzymuje.

Co wchodzi w zakres, a co nie?

Wspólna skrzynka odbiorcza CRM to funkcja zarządzanej chmury od planu Pro wzwyż. Self-hosting koncentruje się na otwartym rdzeniu CRM i zewnętrznych klientach MCP.

Jak uruchomić CRM self hosted na Dockerze?

Instalacja opiera się na dwóch plikach, docker-compose.yml i .env, oraz jednym poleceniu. Potrzebujesz Dockera z Docker Compose v2; obraz działa na linux/amd64 i linux/arm64, a domena jest potrzebna dopiero do HTTPS. Nie klonujesz repozytorium i niczego nie budujesz.

1. Pobierz z repozytorium projektu plik docker-compose.yml i szablon .env.
2. Zanim ruszysz po raz pierwszy, uzupełnij w .env co najmniej hasło do bazy, sekret podpisujący sesje, adres BASE_URL oraz dane usługi wysyłki e-maili. Zmiana hasła do bazy po pierwszym starcie nie zmienia już istniejącej bazy, więc ustaw je od razu.
3. Uruchom docker compose up -d. Pierwszy start trwa około minuty, bo aplikacja wykonuje migracje bazy.
4. Otwórz <BASE_URL>/auth/signup, zarejestruj się, wybierz Utwórz nową przestrzeń roboczą i dokończ kreator: Twoje konto dostaje rolę administratora.

Pod publicznym adresem postaw reverse proxy, na przykład Caddy, nginx lub Traefik, i ustaw BASE_URL na adres z https://. Pełną listę zmiennych środowiskowych i opis konfiguracji znajdziesz w instrukcji self-hostingu.

Co robisz po instalacji: aktualizacje, kopie zapasowe i dostęp

Samo uruchomienie to początek. Na Tobie zostają trzy rzeczy, które w chmurze robi dostawca:

• Aktualizacje. Zrób kopię zapasową, a potem docker compose pull i docker compose up -d. Obraz latest jest budowany z gałęzi głównej, więc każda aktualizacja może przynieść nowe funkcje i migracje bazy. Migracje idą tylko do przodu: aby wrócić do starszej wersji, przywróć kopię zapasową i uruchom poprzedni obraz po tagu sha-. Jeśli chcesz sam decydować, kiedy aktualizować, przypnij obraz do konkretnego tagu zamiast latest.
• Dostęp. Zarejestrować się może każdy, kto dotrze do Twojego BASE_URL, a rejestracji nie da się wyłączyć. Jeśli instancja ma służyć jednemu zespołowi, ogranicz dostęp przez VPN, listę dozwolonych adresów IP albo uwierzytelnianie na reverse proxy; klienci MCP i REST potrzebują wtedy tego samego dostępu.
• E-maile. Bez działającego klucza usługi wysyłki nikt nie potwierdzi adresu e-mail, a nowe konta zostają zablokowane po 24 godzinach.

Kopie zapasowe mają sens dopiero wtedy, gdy raz sprawdzisz, że da się z nich odtworzyć działającą instancję.

Jak wybrać CRM self hosted?

Te pytania warto zadać każdemu projektowi, który rozważasz, także Customermates:

• Licencja i edycje. Które części kodu są open source, a które komercyjne? Wersje Community i Enterprise potrafią różnić się zarówno funkcjami, jak i prawem do ich używania.
• Zakres wersji self-hosted. Co z funkcji chmury działa na Twoim serwerze, a co zostaje tylko w chmurze?
• Wymagania i utrzymanie. Jakie usługi musisz postawić obok aplikacji, kto robi kopie zapasowe i kto sprawdza ich odtwarzanie?
• Dostosowanie i integracje. Czy pola, listy i widoki ustawisz bez programisty i czy system ma REST API oraz webhooki?
• Dane i odpowiedzialność. Gdzie trafiają dane, które dostawcy je przetwarzają i kto odpowiada za konfigurację, umowy i retencję?

Odpowiedzi na te pytania są ważniejsze niż długość listy funkcji, bo to one decydują, ile pracy dołożysz po wdrożeniu.

Granice między kodem open source a komercyjnym

Materiał własny Customermates poza katalogiem ee/ jest objęty licencją AGPL-3.0-only. W ee/ materiał ma licencję komercyjną, z wyjątkiem obrazów, czcionek, CSS i JavaScriptu po stronie klienta, wskazanych jako AGPL Client Material w sekcji 6 pliku ee/LICENSE.md. Przed modyfikowaniem, dalszym rozpowszechnianiem lub uruchamianiem oprogramowania do własnych celów przeczytaj obie licencje.

To rozróżnienie ma znaczenie, gdy porównujesz CRM open source: samo publiczne repozytorium nie mówi, jakiego kodu wolno Ci używać na jakich warunkach. Jeśli rozważasz inne projekty, które da się hostować samodzielnie, porównania z EspoCRM i Twenty pokazują, czym różnią się ich wdrożenie i granice licencji.

Jaką kontrolę daje self-hosting?

Sam wybierasz, gdzie działają aplikacja i PostgreSQL, oraz jak konfigurujesz dostęp sieciowy, kopie zapasowe, retencję i aktualizacje. To realna kontrola nad infrastrukturą, ale nie automatyczna gwarancja zgodności, bezpieczeństwa ani pracy bez dostępu do sieci.

Podłączone usługi pozostają osobnymi granicami przetwarzania. Dostawcy OAuth, Resend do e-maili, monitoring, narzędzia do przepływów pracy i zewnętrzni dostawcy AI otrzymują to, co wyśle do nich Twoja konfiguracja. Diagnostyka błędów zostaje na Twoim serwerze; powiadomienia dla operatora korzystają z odbiorcy i dostawcy poczty, których skonfigurujesz. To nie jest ogólna obietnica braku telemetrii.

Self-hosted czy zarządzana chmura?

Jeśli chcesz wypróbować Customermates, zanim postawisz własny serwer, strona CRM open source w chmurze albo self-hosted zestawia obie drogi obok siebie, a bezpłatny okres próbny w chmurze to najszybszy start.

Rekordy przenosisz między instalacjami lub z innego CRM jako skoroszyty XLSX, po jednym typie rekordu naraz i w granicach limitów wierszy, albo przez REST API, które potrafi też wgrywać pliki do pól typu Plik. Import XLSX nie przenosi załączników, a pełnego transferu konta nie ma, więc większą przeprowadzkę zaplanuj jako projekt migracji, który sam sprawdzisz.

Najczęstsze pytania