Alternatywy dla Slacka z własnym hostingiem: porównanie

Którą alternatywę dla Slacka z własnym hostingiem wybrać

Wartościowe alternatywy dla Slacka z własnym hostingiem, które są odpowiednie dla małych zespołów, to Mattermost, Rocket.Chat, Matrix z Synapse oraz Zulip. W przypadku wewnętrznego narzędzia zespołowego działającego na jednym serwerze należy wybrać Mattermost. Dla społeczności publicznej odpowiednim wyborem jest Zulip. Matrix z Synapse należy uruchomić tylko wtedy, gdy wymagana jest komunikacja z serwerami zewnętrznymi, ponieważ federacja jest unikalną cechą, której inne rozwiązania nie oferują, a jednocześnie znacząco zmienia ona zakres obowiązków administratora.

Listy funkcji nie pozwalają na łatwe rozróżnienie tych czterech rozwiązań. Wszystkie obsługują kanały, wątki, wyszukiwarkę, przesyłanie plików oraz aplikacje mobilne. Różnice wynikają z wymagań stawianych administratorowi każdego miesiąca: zużycia pamięci, bazy danych wymagającej utrzymania, ścieżki powiadomień push, nad którą można nie mieć kontroli, oraz licencji określającej, czy potrzebna funkcja jest płatna. Poniższe porównanie opiera się na tych kryteriach przy założeniu obsługi dziesięciu oraz stu użytkowników.

Czym w rzeczywistości jest każde z tych czterech rozwiązań

Mattermost to serwer napisany w Go, korzystający z bazy danych PostgreSQL. Jeden plik binarny, jedna baza danych, jeden plik konfiguracyjny. Działa podobnie do Slacka, obsługuje wątki oraz komendy typu slash i jest najmniej kłopotliwy w utrzymaniu z całej czwórki, co należy uznać za zaletę.

Rocket.Chat to aplikacja Node.js działająca w oparciu o MongoDB. Oferuje najszerszy zestaw funkcji w tym zestawieniu, w tym połączenia głosowe i wideo oraz skrzynkę odbiorczą typu omnichannel, która integruje rozmowy z klientami z poczty e-mail i kanałów społecznościowych w jednym interfejsie. Jeśli to właśnie ta skrzynka jest powodem zainteresowania, warto najpierw rozważyć dedykowane wsparcie techniczne Chatwoot, ponieważ serwer czatu pełniący funkcje wsparcia klienta to inne zadanie niż serwer czatu do pracy zespołowej.

Matrix to protokół, a nie produkt. Synapse jest serwerem referencyjnym (Python, PostgreSQL), a Element to klient, z którego korzysta większość użytkowników. Jest to jedyna opcja w zestawieniu, w której Twój serwer może komunikować się z serwerami, których nie administrujesz.

Zulip to serwer w języku Python (Django oraz Tornado) z bazą PostgreSQL, RabbitMQ, memcached i Redis w tle, instalowany jako jedna całość za pomocą dedykowanego skryptu. Jego model opiera się na tematach wewnątrz kanałów, dzięki czemu rozmowę z wtorku można łatwo odnaleźć w piątek. Wersja 12.0 została wydana w kwietniu 2026.

Zapotrzebowanie na pamięć RAM i wybór bazy danych dla 10 oraz 100 użytkowników

Każda liczba w poniższej tabeli pochodzi z dokumentacji projektu, odczytanej w sierpniu 2026 roku. Żadna z nich nie jest wynikiem własnych pomiarów ani nie została zmyślona. Podstawa dla każdego wiersza jest identyczna: najmniejsza konfiguracja publikowana przez projekt, z uwzględnieniem bazy danych, jeśli projekt wycenia ją osobno.

[
  {
    "label": "Synapse",
    "published_ram_gb": 1,
    "notes": "Synapse install docs: at least 1 GB free RAM if you want to join large public rooms. PostgreSQL is required for production and is not sized."
  },
  {
    "label": "Mattermost",
    "published_ram_gb": 2,
    "notes": "Mattermost requirements: 1 to 1,000 users on 1 vCPU and 2 GB RAM, single server, database included."
  },
  {
    "label": "Zulip",
    "published_ram_gb": 2,
    "notes": "Zulip requirements: under 100 users on 1 CPU, 2 GB RAM and 2 GB swap. 100 users and above needs 2 CPUs and 4 GB."
  },
  {
    "label": "Rocket.Chat",
    "published_ram_gb": 8,
    "notes": "Rocket.Chat requirements: smallest published tier is 4 GiB for the app plus 4 GiB for MongoDB, rated up to 500 concurrent users."
  }
]

Wiersze nie mają tej samej struktury i jest to pierwszy istotny wniosek. Wartość 1 GB dla Synapse to minimum dla procesu Synapse z zastrzeżeniem: dokumentacja wymaga co najmniej tyle wolnej pamięci RAM w przypadku dołączania do dużych pokoi publicznych. PostgreSQL nie wlicza się do tej wartości. Wartość 2 GB dla Mattermost dotyczy całej maszyny, włącznie z bazą danych, i obejmuje od 1 do 1000 użytkowników na jednym vCPU. Zulip wymaga 2 GB RAM i jednego procesora dla mniej niż 100 użytkowników, plus 2 GB swap, a powyżej 100 użytkowników – 4 GB RAM i dwóch procesorów. Rocket.Chat podaje najwyższą wartość, 8 GB, ponieważ wycenia aplikację na 4 GiB, a MongoDB na 4 GiB; ten poziom jest przewidziany dla maksymalnie 500 jednoczesnych użytkowników.

Przy dziesięciu użytkownikach wszystkie 4 rozwiązania działają na sprzęcie, nad którym nie trzeba się zastanawiać. Przy stu użytkownikach odpowiedzi stają się rozbieżne: Mattermost nadal mieści się w swoim poziomie 2 GB, Zulip wymaga 4 GB i drugiego procesora, a najmniejszy udokumentowany poziom Rocket.Chat pozostaje bez zmian na poziomie 8 GB, ponieważ zapotrzebowanie MongoDB na pamięć jest determinowane przez maszynę, a nie przez liczbę użytkowników.

Wybór bazy danych w większym stopniu determinuje przyszłe aktualizacje niż codzienna wydajność. Mattermost wymaga PostgreSQL 14 lub nowszego i wycofał wsparcie dla MySQL począwszy od wersji v11, więc instalacja oparta na MySQL oznacza konieczność przyszłej migracji. Synapse działa na SQLite, a dokumentacja wprost wskazuje, że SQLite jest dopuszczalne tylko do testów, ponieważ działa nieefektywnie w dużych pokojach. Rocket.Chat 8 wymaga MongoDB 8.0, co oznacza, że aktualizacja bazy danych i komunikatora stanowi jeden projekt, a nie dwa osobne.

Co faktycznie oferuje VPS z 2 GB pamięci RAM

Plan 2 GB to najniższa konfiguracja u większości dostawców i stanowi ona realne rozwiązanie dla dwóch z czterech wymienionych usług.

• Mattermost działa poprawnie. Jest to jedyna usługa, dla której producent dokumentuje właśnie ten rozmiar pamięci dla maksymalnie 1000 użytkowników, przy założeniu, że PostgreSQL działa na tej samej maszynie. Obsługa dziesięciu osób przy 2 GB RAM jest komfortowa.
• Zulip działa, pod warunkiem użycia swap. Dokumentacja zaleca partycję wymiany dla każdej maszyny z mniej niż 5 GB RAM i ostrzega, że systemy z małą ilością pamięci napotykają błędy braku pamięci (OOM) podczas aktualizacji, gdzie tools/webpack jest krokiem, który kończy się niepowodzeniem. Jest to realny problem, który wystąpi w momencie aktualizacji, a nie podczas instalacji.
• Synapse działa, dopóki ruch jest niewielki. Koszt utrzymania w stanie spoczynku jest niski. Problemem są skoki obciążenia, a sekcja dotycząca federacji poniżej wyjaśnia ich źródło.
• Rocket.Chat to usługa, której należy unikać przy 2 GB RAM, a przyczyną jest silnik pamięci masowej MongoDB. WiredTiger ustala rozmiar wewnętrznej pamięci podręcznej jako większą z wartości: 50% (RAM minus 1 GB) lub 256 MB. Na maszynie z 2 GB RAM rezerwuje on około 512 MB jeszcze przed uruchomieniem Node.js. Skutkiem nie jest czysta odmowa działania. Usługa instaluje się i uruchamia, ale zwalnia wraz z przyrostem historii, aż w końcu mechanizm OOM killer jądra systemu przerywa proces, który w danej chwili zajmuje najwięcej pamięci.

Przed podjęciem decyzji sprawdź, czym faktycznie dysponujesz, ponieważ dostawcy liczą pamięć RAM inaczej niż free:

free -h
swapon --show

Pamiętaj, że serwer czatu nie jest jedynym procesem na maszynie. Terminacja TLS (transport layer security), kopie zapasowe oraz środowisko uruchomieniowe kontenerów również wymagają pamięci. Wybrany serwer umieść za reverse proxy, które znasz, takim jak Nginx, Caddy lub Traefik, a jeśli wdrażasz rozwiązania za pomocą kontenerów, podstawy Docker Compose dla VPS są elementem, który warto poprawnie skonfigurować w pierwszej kolejności.

Czy aplikacje mobilne wymagają własnego serwera powiadomień push

Jest to kwestia, którą użytkownicy odkrywają po wdrożeniu i która najczęściej determinuje ostateczną decyzję.

Mechanizm działania wygląda następująco. Apple Push Notification service (APNs) oraz Firebase Cloud Messaging (FCM) akceptują powiadomienie wyłącznie od podmiotu posiadającego poświadczenia podpisywania dla danej aplikacji. Własny serwer nie może wysłać powiadomienia do aplikacji, której użytkownik nie zbudował samodzielnie. Zatem serwer czatu hostowany we własnym zakresie, korzystający z oficjalnej wersji aplikacji ze sklepu, musi przekazać powiadomienia do bramki dostawcy, a ten narzuca własne warunki.

• Mattermost. Darmową ścieżką jest Test Push Notification Service (TPNS) pod adresem https://push-test.mattermost.com, który według dokumentacji nie jest zalecany do środowisk produkcyjnych i nie posiada umowy o gwarantowanym poziomie świadczenia usług (SLA). Działa on wyłącznie z wersjami aplikacji pobranymi z App Store i Play Store. Hosted Push Notification Service (HPNS) jest rozwiązaniem klasy produkcyjnej i wymaga płatnej subskrypcji. Trzecią drogą jest samodzielna kompilacja serwera proxy powiadomień, co z kolei wymaga zbudowania własnych wersji aplikacji z własnymi poświadczeniami APNs i FCM.
• Rocket.Chat. Powiadomienia push wymagają zarejestrowania obszaru roboczego w Rocket.Chat Cloud, a w przypadku wersji społecznościowych limit wynosi 10 000 powiadomień push miesięcznie. Daje to około 330 powiadomień dziennie dla całego obszaru roboczego. Po wyczerpaniu limitu powiadomienia przestają docierać do momentu zresetowania cyklu miesięcznego, co dla użytkowników wygląda jak awaria aplikacji.
• Matrix z Element. Synapse wysyła powiadomienia do bramki push, a oficjalne aplikacje Element są skierowane na bramkę utrzymywaną przez matrix.org pod adresem https://matrix.org/_matrix/push/v1/notify. Ładunek (payload) zawiera identyfikatory zdarzeń i pokoi, a nie treść wiadomości, ponieważ aplikacja pobiera zawartość bezpośrednio z Twojego serwera. Dzięki temu bramka widzi jedynie metadane, a nie treść rozmów. Uruchomienie własnej bramki Sygnal jest wspierane, ale wiąże się z koniecznością budowania i dystrybucji własnych aplikacji. W systemie Android istnieje rozwiązanie pośrednie: UnifiedPush z serwerem ntfy hostowanym we własnym zakresie.
• Zulip. Darmowy plan obejmuje mobilną usługę push dla maksymalnie 10 użytkowników. Powyżej 10 użytkowników wymagany jest płatny plan, przy czym darmowy plan Community obejmuje wiele organizacji niekomercyjnych. Wersja Zulip 12.0, wydana w kwietniu 2026, wprowadziła szyfrowanie end-to-end dla ładunków powiadomień push.

Przy dziesięciu użytkownikach każde z tych rozwiązań zapewnia działające powiadomienia bez ponoszenia kosztów. Przy stu użytkownikach sytuacja się zmienia: Zulip wymaga planu płatnego, Mattermost nadal działa na usłudze testowej bez SLA i wsparcia technicznego, miesięczny limit Rocket.Chat staje się ograniczeniem, natomiast Matrix pozostaje bez zmian, ponieważ korzystanie z bramki jest darmowe.

Które z nich oferują single sign-on bezpłatnie

Single sign-on (SSO) to obszar, w którym model biznesowy open core jest najbardziej widoczny.

• Zulip zawiera obsługę SAML (security assertion markup language) oraz LDAP (lightweight directory access protocol) w wersji self-hosted bez dodatkowych kosztów. Nie istnieje osobny płatny poziom dostępu.
• Synapse wspiera OpenID Connect (OIDC), SAML oraz CAS w swoim pliku konfiguracyjnym, bezpłatnie. Nowsze wdrożenia coraz częściej korzystają z Matrix Authentication Service, czyli osobnej usługi z jednostronną migracją z klasycznego uwierzytelniania Synapse, dlatego warto zaplanować ten krok wcześniej, zamiast odkrywać go w trakcie pracy.
• Rocket.Chat w wersji community oferuje podstawowe logowanie przez LDAP i SAML. Synchronizacja rozszerzonych atrybutów użytkownika, mapowanie grup i zespołów oraz synchronizacja w tle wymagają licencji enterprise.
• Mattermost w bezpłatnej wersji Team Edition oferuje jedynie GitLab OAuth. SAML, AD/LDAP oraz OpenID Connect to funkcje płatne.

Jeśli planujesz uruchomienie kilku usług za jednym panelem logowania, umieść przed nimi samodzielnie hostowanego dostawcę tożsamości Authentik i sprawdź, które z tych czterech rozwiązań faktycznie będzie z nim współpracować w ramach posiadanej przez Ciebie licencji.

Rzeczywiste koszty federacji

Federacja jest powodem istnienia Matrix. Użytkownik dołącza do pokoju hostowanego na serwerze innej osoby i rozmawia z użytkownikami, których konta tam się znajdują, podobnie jak serwery pocztowe wymieniają wiadomości e-mail. Żadna inna opcja tutaj tego nie oferuje. Jeśli jest to wymagane, nic innego na tej stronie nie stanowi zamiennika.

Jest to również powód, dla którego Synapse stanowi inny rodzaj obciążenia. Gdy użytkownik dołącza do sfederowanego pokoju, serwer pobiera kopię stanu tego pokoju oraz jego zdarzenia, a także buforuje media publikowane przez użytkowników z innych serwerów: awatary, obrazy i pliki. Wykorzystanie dysku jest zatem determinowane przez pokoje, których nie utworzono lokalnie, oraz przez osoby, które nie posiadają kont na danym serwerze. Dlatego instalacje Synapse generują magazyn mediów znacznie większy niż wolumen wiadomości wysłanych przez własnych użytkowników. Jest to również powód, dla którego dołączanie do dużego publicznego pokoju jest operacją, dla której dokumentacja określa konkretne wymagania dotyczące pamięci RAM.

Zasady retencji należy ustawić pierwszego dnia, a nie w dniu zapełnienia dysku:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Synapse zyskało media_retention w wersji 1.61, wprowadzając oddzielne czasy życia dla mediów lokalnych i zdalnych. Media zdalne stanowią pamięć podręczną, więc jeśli użytkownik ponownie poprosi o usunięty plik, Synapse pobierze go ponownie z serwera źródłowego. Media lokalne nie są pamięcią podręczną, więc krótki czas local_media_lifetime trwale usuwa pliki przesłane przez własnych użytkowników.

Uczciwe podsumowanie: jeśli użytkownicy rozmawiają tylko ze sobą, federacja nie przynosi żadnych korzyści, a generuje koszty w postaci zajętości dysku, zużycia pasma i trudniejszej ścieżki aktualizacji. Należy ją wyłączyć lub wybrać inny serwer.

Jak przebiegają aktualizacje

Zulip jest najprostszy. Jeden skrypt, a udokumentowany czas przestoju wynosi poniżej 30 sekund, chyba że wymagana jest duża migracja bazy danych. Instalacja i aktualizacja wyglądają następująco i są wykonywane przez użytkownika na serwerze:

cd $(mktemp -d)
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
tar -xf zulip-server-latest.tar.gz

Uruchom instalator jako root. Flaga --push-notifications rejestruje serwer w usłudze powiadomień mobilnych podczas instalacji i w tym momencie prosi o zaakceptowanie warunków świadczenia usług, więc zapoznaj się z nimi przed rozpoczęciem.

sudo ./zulip-server-*/scripts/setup/install --push-notifications --certbot \
    --email=YOUR_EMAIL --hostname=YOUR_HOSTNAME

Późniejsze aktualizacje to ten sam plik tarball oraz jedno polecenie:

curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
sudo /home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz

Mattermost jest przewidywalny. Zastąp plik binarny, zrestartuj usługę, a migracje zostaną wykonane przy starcie. Od wydań z sierpnia 2025 roku ścieżka Extended Support Release (ESR) jest publikowana co 9 miesięcy i objęta 12-miesięcznym wsparciem, a aktualizacje między wersjami ESR są ścieżką przetestowaną. Pomijanie kilku wersji ESR jednocześnie jest obsługiwane, ale nieprzetestowane, co w praktyce oznacza, że użytkownik sam przeprowadza testy.

Rocket.Chat łączy trzy aktualizacje w jedną. Od sierpnia 2026 roku aktualna jest linia 8.x, z wersją 8.7.0 wydaną 6 sierpnia 2026 roku, która wymaga MongoDB 8.0 oraz odpowiedniej wersji Node.js. Pomijanie głównej wersji to sposób, w jaki użytkownicy kończą z bazą danych, której aplikacja odmawia otwarcia. Przewodnik instalacji Rocket.Chat przez Docker Compose wiąże te elementy ze sobą, co stanowi główny argument za wyborem metody kontenerowej w tym przypadku.

Synapse wymaga czytania. Każde wydanie posiada notatki aktualizacyjne i należy zapoznać się z notatkami dla każdej wersji, przez którą przechodzisz, a nie tylko dla tej docelowej. Po aktualizacji Synapse uruchamia w tle procesy aktualizacji bazy danych. Na małym serwerze mogą one spowalniać maszynę przez wiele godzin i jest to oczekiwane zachowanie, a nie błąd.

Warunki licencyjne w prostych słowach

Mattermost udostępnia skompilowane kompilacje Team Edition na licencji MIT, podczas gdy kod źródłowy jest oferowany na licencji AGPLv3 lub licencji komercyjnej, przy czym części repozytorium podlegają Mattermost Source Available License, która wymaga płatnej licencji do użytku produkcyjnego. Rocket.Chat jest objęty licencją MIT, z wyjątkiem katalogów ee/, które posiadają własną licencję enterprise. Synapse zmieniło licencję z Apache 2.0 na AGPLv3 wraz z wersją 1.99.0, a współtwórcy podpisują CLA, które pozwala firmie Element sprzedawać wyłączenia z tej licencji. Zulip korzysta z licencji Apache 2.0 i nie posiada katalogu enterprise, dlatego jego obsługa SSO nie zawiera żadnych zastrzeżeń.

Praktyczne znaczenie: licencja AGPL ma znaczenie tylko w przypadku modyfikacji serwera i oferowania go innym jako usługi. Dla małego zespołu znacznie ważniejszy jest model open core, czyli informacja o tym, których funkcji brakuje w darmowej wersji. Zulip ma ich najmniej, a Mattermost najwięcej.

Które rozwiązanie wybrać

Wewnętrzne narzędzie zespołowe. Mattermost. Charakteryzuje się najmniejszym udokumentowanym zapotrzebowaniem na zasoby, najbardziej przewidywalnym procesem aktualizacji oraz interfejsem, który nie wymaga dodatkowych wyjaśnień. Należy zaplanować przejście na płatny plan w momencie, gdy SSO stanie się wymagane, ponieważ większość zespołów prędzej czy później dochodzi do tego etapu.

Serwer społecznościowy. Zulip. Dzięki wątkom (topics) nawet bardzo aktywne kanały publiczne pozostają czytelne po wielu miesiącach. Obsługa SAML oraz LDAP jest dostępna bez dodatkowych opłat, a aktualizacja sprowadza się do wykonania jednego polecenia. Jeśli charakter społeczności jest bliższy publikowaniu postów i odpowiedzi niż czatu na żywo, warto najpierw rozważyć oprogramowanie forum self-hosted, ponieważ fora lepiej indeksują się w wyszukiwarkach i nie wymagają infrastruktury do obsługi powiadomień push. Wybierz Rocket.Chat, jeśli potrzebujesz funkcji głosowych, wideo oraz obsługi wielu kanałów komunikacji (omnichannel) i jesteś w stanie zapewnić mu 8 GB pamięci RAM, zgodnie z wymaganiami dokumentacji.

Sieć wymagająca interoperacyjności. Matrix z Synapse oraz Element. Należy zaakceptować wzrost zajętości miejsca przez pliki multimedialne, od pierwszego dnia skonfigurować retencję danych, zapewnić bazę PostgreSQL oraz większą przestrzeń dyskową, niż początkowo zakładano. Pozwala to na realne korzyści z komunikacji z serwerami, nad którymi nie sprawuje się kontroli. Wybór Synapse dla zespołu, który nigdy nie będzie korzystał z federacji, oznacza ponoszenie kosztów utrzymania bez żadnych korzyści.

FAQ

Jaka jest najlepsza alternatywa dla Slacka do samodzielnego hostowania dla małego zespołu?

Dla większości wewnętrznych zespołów jest to Mattermost. Dokumentacja wskazuje, że obsłuży od 1 do 1000 użytkowników na jednym vCPU i 2 GB RAM z PostgreSQL na tej samej maszynie, więc mieści się w podstawowych planach VPS oferowanych przez większość dostawców. Haczykiem jest logowanie jednokrotne (SSO): darmowa edycja Team Edition obsługuje wyłącznie GitLab OAuth, natomiast SAML, AD/LDAP oraz OpenID Connect wymagają płatnego planu. Jeśli darmowe SSO jest ważniejsze niż interfejs w stylu Slacka, należy uruchomić Zulip.

Czy mogę uruchomić serwer czatu na VPS z 2 GB RAM?

Mattermost tak, a Zulip również, pod warunkiem dodania partycji swap, co zaleca dokumentacja Zulip dla systemów z mniej niż 5 GB RAM. Rocket.Chat może rozczarować, ponieważ silnik WiredTiger bazy MongoDB rezerwuje dla swojego cache'u większą z wartości: 50% (RAM minus 1 GB) lub 256 MB. Oznacza to, że około 512 MB z 2 GB pamięci jest zajęte jeszcze przed uruchomieniem aplikacji. Instalacja przebiegnie pomyślnie, ale wydajność spadnie wraz z przyrostem historii, co zakończy się błędem out of memory. Najmniejsza zalecana konfiguracja dla Rocket.Chat to 4 GiB dla aplikacji oraz 4 GiB dla MongoDB.

Czy serwery czatu wymagają własnego serwera powiadomień push?

Zazwyczaj nie, ponieważ Apple APNs oraz Google FCM akceptują powiadomienia tylko od podmiotu, który podpisał aplikację, więc oficjalna aplikacja korzysta z bramki dostawcy. Warunki różnią się w zależności od oprogramowania. Mattermost oferuje darmową usługę testową bez SLA oraz płatną usługę hostowaną. Rocket.Chat ogranicza darmowe przestrzenie robocze do 10 000 powiadomień push miesięcznie, po czym dostarczanie zostaje wstrzymane do początku kolejnego miesiąca. Zulip oferuje darmowe powiadomienia dla maksymalnie 10 użytkowników, powyżej tej liczby wymagany jest płatny plan. Serwery domowe Matrix przesyłają powiadomienia przez bramkę używaną przez aplikacje Element bez dodatkowych opłat. Własna bramka jest potrzebna tylko w przypadku dystrybucji własnych kompilacji aplikacji.

Czy warto hostować Matrix i Synapse dla zespołu, który nie komunikuje się z innymi serwerami?

Nie. Federacja jest głównym przeznaczeniem Synapse i jednocześnie powodem, dla którego wymaga ona większych zasobów. Dołączanie do pokoi na innych serwerach powoduje pobieranie ich stanu i buforowanie mediów na dysku, więc zajętość pamięci rośnie z przyczyn niezależnych od własnych użytkowników. Należy ustawić media_retention z krótkim remote_media_lifetime, zanim do tego dojdzie. Zespół komunikujący się wyłącznie wewnątrz organizacji ponosi koszty operacyjne bez żadnych korzyści, a Mattermost lub Zulip wykonają to samo zadanie na słabszym sprzęcie.

Która alternatywa dla Slacka oferuje darmowe logowanie jednokrotne (SSO)?

Zulip oraz Synapse. Zulip zawiera obsługę SAML i LDAP w darmowej wersji serwera, a Synapse wspiera OpenID Connect, SAML i CAS w swojej konfiguracji, przy czym nowsze instalacje przechodzą na oddzielny Matrix Authentication Service. Edycja społecznościowa Rocket.Chat obsługuje podstawowe logowanie LDAP i SAML, ale synchronizacja atrybutów, mapowanie grup i synchronizacja w tle wymagają licencji enterprise. Darmowa edycja Team Edition oprogramowania Mattermost obsługuje wyłącznie GitLab OAuth.