Cała praca dzieje się na czacie. Ustalenia z klientami, hasła wrzucone „na chwilę”, zrzuty ekranu z panelu, decyzja sprzed pół roku. A wszystko to leży na cudzych serwerach: w darmowym Slacku starsza historia znika za paywallem, w Teams — za licencjami, a w grupach na Telegramie nikt już nie wie, kto jeszcze w nich siedzi.

Najbardziej boli to, gdy ktoś odchodzi z zespołu. Trzeba go ręcznie usunąć z kilkunastu grup, a kopia rozmów i tak zostaje na jego telefonie. Jeśli konto było prywatne, nie masz nad nim żadnej kontroli.

Własny czat rozwiązuje ten problem. Serwer jest Twój, baza jest Twoja, logowanie idzie przez Twój katalog użytkowników. Wyłączasz konto w jednym miejscu — dostęp znika.

Co robimy

Typowy układ, który stawiamy na serwerze dedykowanym w OVH lub Hetznerze albo w istniejącym Proxmoksie:

  • Czat — Mattermost (częściej) lub Rocket.Chat w osobnej maszynie wirtualnej albo kontenerze LXC.
  • Baza — PostgreSQL dla Mattermosta, MongoDB z replica setem dla Rocket.Chata.
  • Pliki — na dysku lokalnym albo w magazynie zgodnym z S3 (MinIO, Object Storage w Hetznerze lub OVH). Gdy zespół dużo wrzuca zrzutów i PDF-ów, S3 jest wygodniejsze: dysk maszyny nie puchnie, a kopia plików żyje osobno.
  • Logowanie — przez SSO: Keycloak, Authentik albo Twój LDAP/Active Directory.
  • Dostęp z zewnątrz — Nginx lub Traefik z certyfikatem Let’s Encrypt, fail2ban i limit zapytań na stronę logowania.
  • Integracje — kanały na alerty z Prometheusa/Alertmanagera, komunikaty z GitLab CI i wdrożeń.
  • Backup i monitoring — codzienny zrzut bazy i kopia plików na osobne miejsce, kontrola dostępności i ważności certyfikatu.

Mattermost czy Rocket.Chat — uczciwie

Mattermost działa na PostgreSQL i jest jedną binarką. Utrzymanie jest prostsze: aktualizacja to podmiana wersji i migracje bazy, które robi sam. Świetnie współpracuje z GitLabem — gotowa integracja, komendy slash, powiadomienia o merge requestach i pipeline’ach. Dla zespołów technicznych to zwykle najlepszy wybór.

Dane trzyma w zwykłych tabelach, więc w razie potrzeby odpowiedź da się wyciągnąć prosto z bazy zapytaniem SQL. Warto wiedzieć o jednym: usunięta wiadomość jest w bazie tylko oznaczana jako usunięta, a nie znika. Dla audytu to zaleta. Dla kogoś, kto myślał, że „skasował i po sprawie” — niespodzianka.

Rocket.Chat daje więcej od ręki: omnichannel do obsługi klientów, wideorozmowy, więcej ustawień interfejsu. Jest jednak cięższy. Potrzebuje MongoDB z replica setem nawet na jednym serwerze, a MongoDB między wersjami głównymi trzeba aktualizować krok po kroku, przez każdą pośrednią.

Oba mają darmowe edycje, ale producenci w ostatnich latach kilka razy zmieniali ich warunki: co wchodzi, ilu użytkowników, które funkcje zostały w planach płatnych. Dlatego niczego nie obiecujemy z góry — przed startem sprawdzamy aktualne warunki pod Twoją liczbę osób i potrzebne funkcje. Na przykład w Mattermoście ogólne logowanie przez OpenID Connect, SAML i LDAP historycznie było w edycjach płatnych, a darmowa obsługiwała logowanie przez GitLaba. Od tego zależy, jak dokładnie podepniemy SSO.

Kiedy własny czat się NIE opłaca: gdy jest was pięcioro, nikogo nie trzeba odcinać i nikt nie potrzebuje historii z trzech lat. Wtedy koszt serwera i utrzymania się nie zwróci.

Powiadomienia push, SSO i odejścia z firmy

Powiadomienia push to najmniej oczywista część. Oficjalne aplikacje mobilne dostają pushe przez usługi Apple i Google, a te przyjmują je tylko od wydawcy aplikacji. Twój serwer wysyła więc powiadomienie przez push proxy producenta, a dopiero ono do Apple czy Google. Tu zależysz od cudzej usługi i jej warunków. Żeby treść wiadomości nie wychodziła na zewnątrz, włączamy tryb, w którym push niesie tylko identyfikator, a treść telefon pobiera z Twojego serwera. Całkiem własne push proxy jest możliwe, ale wymaga budowania własnych aplikacji mobilnych — dla małego zespołu to zwykle przesada.

Stąd drugi kompromis: czatu nie schowasz za VPN-em ani za wspólną bramką logowania przed stroną. Aplikacje mobilne i desktopowe rozmawiają z API bezpośrednio. Dlatego chronimy samą aplikację: SSO z drugim składnikiem, fail2ban, limity zapytań.

SSO ustawiamy tak, żeby ludzie logowali się tym samym kontem co do poczty czy GitLaba. Przed przełączeniem łączymy istniejące konta po adresie e-mail, żeby nie powstały duplikaty. Osobno sprawdzamy adres serwisu w konfiguracji: jeśli został tam adres wewnętrzny, logowanie przez SSO i linki w pushach po prostu nie zadziałają.

Odejście z firmy: wyłączasz osobę w katalogu — nie zaloguje się ponownie. Otwarte sesje żyją jednak do końca ważności, więc ustawiamy rozsądny czas sesji i spisujemy krótką instrukcję na dzień odejścia.

Integracje. Mattermost przyjmuje webhooki w formacie Slacka, więc Alertmanager wysyła alerty bez żadnych dodatków:

receivers:
  - name: chat-alerts
    slack_configs:
      - api_url_file: /etc/alertmanager/chat_webhook
        channel: alerts
        send_resolved: true
        title: '{{ .CommonLabels.alertname }}: {{ .Status }}'

GitLab CI tak samo pisze na kanał o zepsutym pipelinie czy udanym wdrożeniu.

Backup i aktualizacje. Zrzut bazy i kopia plików — osobno, na inne miejsce, ze sprawdzonym odtworzeniem. Aktualizujemy według planu: najpierw snapshot maszyny, potem nowa wersja, potem test logowania, pushy i webhooków.

Co dostajesz

  • Firmowy czat na Twoim serwerze, z Twoją domeną i TLS.
  • Logowanie przez SSO i jasną procedurę przy odejściu pracownika.
  • Aplikacje mobilne i desktopowe ze skonfigurowanymi powiadomieniami.
  • Kanały z alertami z monitoringu i zdarzeniami z CI.
  • Codzienny backup bazy i plików ze sprawdzonym odtworzeniem.
  • Monitoring dostępności, miejsca na dysku i ważności certyfikatu.
  • Dokumentację: co gdzie leży, jak aktualizować, jak odtworzyć z backupu.
  • Pełne dostępy administracyjne — wszystko zostaje u Ciebie, nawet jeśli przestaniemy współpracować.

Jeśli praca rozlała się po grupach na Telegramie albo uderzyliście w limity Slacka — napisz do nas. Powiedz, ilu was jest i czego już używacie, a zaproponujemy, co postawić i jak się przenieść.