Mattermost — self-hosted komunikator dla zespołów deweloperskich
Opublikowano: 10 kwietnia 2026 · Kategoria: VPS
Slack zdominował rynek komunikatorów dla deweloperów, ale jego ograniczenia (historia wiadomości za paywallem, dane na serwerach Salesforce, koszt per-seat) sprawiają, że wiele firm szuka alternatywy. Mattermost to open-source komunikator dla zespołów technicznych, który możesz uruchomić na własnym VPS — z pełną kontrolą nad danymi, bez limitu historii i z bogatym ekosystemem integracji. Ten artykuł pokazuje instalację przez Docker Compose, konfigurację SMTP, integracje z narzędziami deweloperskimi i tuning wydajności dla większych zespołów.
Instalacja przez Docker Compose
Oficjalny Docker Compose dla Mattermost instaluje trzy kontenery: aplikację, PostgreSQL i opcjonalnie Nginx jako reverse proxy. Poniżej minimalna konfiguracja produkcyjna z Let's Encrypt:
# Sklonuj oficjalny repo Mattermost Docker
git clone https://github.com/mattermost/docker
cd docker
cp env.example .env
# Edytuj .env - kluczowe zmienne
# DOMAIN=mattermost.example.com
# MM_SERVICESETTINGS_SITEURL=https://mattermost.example.com
# POSTGRES_USER=mmuser
# POSTGRES_PASSWORD=mmuser_password
# POSTGRES_DB=mattermost
# Utwórz woluminy i nadaj uprawnienia
mkdir -p ./volumes/app/mattermost/{config,data,logs,plugins,client/plugins,bleve-indexes}
sudo chown -R 2000:2000 ./volumes/app/mattermost
# Uruchom stack (bez Nginx - jezeli masz wlasny reverse proxy)
docker compose -f docker-compose.yml -f docker-compose.without-nginx.yml up -d
# Sprawdz status
docker compose ps
docker compose logs -f mattermost Konfiguracja Nginx + Let's Encrypt
Jeśli używasz własnego Nginx (spoza stack Mattermost), dodaj vhost z proxy_pass i WebSocket support. Mattermost wymaga obsługi WebSocket dla real-time wiadomości:
upstream mattermost {
server 127.0.0.1:8065;
keepalive 32;
}
server {
listen 443 ssl;
server_name mattermost.example.com;
ssl_certificate /etc/letsencrypt/live/mattermost.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mattermost.example.com/privkey.pem;
location / {
proxy_pass http://mattermost;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering off;
proxy_read_timeout 600s;
}
} Konfiguracja SMTP i powiadomień email
Mattermost wysyła emaile do weryfikacji konta, resetowania hasła i powiadomień o wzmianakch.
Konfigurację SMTP znajdziesz w System Console → Environment → SMTP lub bezpośrednio
w pliku config/config.json:
# Fragment config.json - sekcja EmailSettings
{
"EmailSettings": {
"SendEmailNotifications": true,
"FeedbackName": "Mattermost",
"FeedbackEmail": "[email protected]",
"ReplyToAddress": "[email protected]",
"SMTPServer": "smtp.gmail.com",
"SMTPPort": "587",
"ConnectionSecurity": "STARTTLS",
"EnableSMTPAuth": true,
"SMTPUsername": "[email protected]",
"SMTPPassword": "app_password_tutaj",
"EnableEmailBatching": true,
"EmailBatchingBufferSize": 256,
"EmailBatchingInterval": 30
}
}
# Zrestartuj po zmianie config.json
docker compose restart mattermost Integracje: GitHub, GitLab i Jira webhooks
Mattermost obsługuje przychodzące webhooks (Incoming Webhooks) do odbierania powiadomień z zewnętrznych systemów. Poniżej konfiguracja dla GitHub:
# 1. Włącz Incoming Webhooks w System Console # System Console → Integrations → Integration Management # Enable Incoming Webhooks = true # 2. Utwórz webhook w Mattermost # Menu → Integrations → Incoming Webhooks → Add Incoming Webhook # Wybierz kanał docelowy (np. #dev-notifications) # Skopiuj URL: https://mattermost.example.com/hooks/xxxx # 3. Dodaj webhook w GitHub # Repo → Settings → Webhooks → Add webhook # Payload URL: https://mattermost.example.com/hooks/xxxx # Content type: application/json # Wybierz events: Push, Pull requests, Issues, Releases # 4. Slash commands - przyklad wlasnej komendy # Menu → Integrations → Slash Commands → Add Slash Command # Command: /deploy # Request URL: https://your-ci-server.com/deploy-hook # Method: POST # Response username: deploy-bot
Integracja z LDAP / Active Directory
LDAP sync pozwala zalogować pracowników korporacyjnym kontem bez tworzenia osobnych kont
Mattermost. W wersji Team Edition (bezpłatnej) dostępny jest plugin open-source LDAP; pełna
synchronizacja grupowa wymaga licencji Enterprise. Konfiguracja w config.json:
"LdapSettings": {
"Enable": true,
"EnableSync": true,
"LdapServer": "ldap.company.com",
"LdapPort": 389,
"ConnectionSecurity": "STARTTLS",
"BaseDN": "OU=Users,DC=company,DC=com",
"BindUsername": "CN=svc-mattermost,OU=ServiceAccounts,DC=company,DC=com",
"BindPassword": "bind_password",
"UserFilter": "(objectClass=person)",
"GuestFilter": "",
"EmailAttribute": "mail",
"UsernameAttribute": "sAMAccountName",
"FirstNameAttribute": "givenName",
"LastNameAttribute": "sn",
"NicknameAttribute": "displayName",
"IdAttribute": "objectGUID",
"SyncIntervalMinutes": 60,
"MaxPageSize": 0
} Performance tuning — DB pooling i Elasticsearch
Przy większych zespołach (200+ aktywnych użytkowników) domyślna konfiguracja PostgreSQL może być wąskim gardłem. Warto dostroić connection pooling oraz włączyć Elasticsearch dla wydajnego wyszukiwania.
| Rozmiar zespołu | RAM aplikacji | RAM PostgreSQL | Elasticsearch | Zalecany VPS |
|---|---|---|---|---|
| Do 50 użytkowników | 1 GB | 512 MB | Nie | 2 GB RAM total |
| 50–200 użytkowników | 2 GB | 1 GB | Opcjonalnie | 4 GB RAM total |
| 200–500 użytkowników | 4 GB | 2 GB | Zalecane (4 GB) | 8–12 GB RAM total |
| 500–2000 użytkowników | 8 GB | 4 GB | Wymagane (8 GB) | 16–24 GB RAM total |
# Elasticsearch w docker-compose.yml (dodaj serwis)
elasticsearch:
image: elasticsearch:7.17.0
environment:
- discovery.type=single-node
- "ES_JAVA_OPTS=-Xms2g -Xmx2g"
- xpack.security.enabled=false
volumes:
- ./volumes/elasticsearch:/usr/share/elasticsearch/data
# config.json - Elasticsearch settings
"ElasticsearchSettings": {
"EnableIndexing": true,
"EnableSearching": true,
"EnableAutocomplete": true,
"ConnectionURL": "http://elasticsearch:9200",
"Username": "",
"Password": "",
"SniffEnabled": false,
"StartOfSchemaVersion": 0,
"BulkIndexingTimeWindowSeconds": 3600
}
# Po konfiguracji - przeliczenie indeksu
# System Console → Environment → Elasticsearch
# "Purge Indexes" a potem "Index Now"