How to Self-Host Mattermost on a KVM VPS with Docker Compose, PostgreSQL and Nginx SSL

10/4/202633 min read

Tropic

mattermost vps self hosted
mattermost docker compose vps
self hosted team chat vps
install mattermost ubuntu vps
slack alternative vps

Quick Takeaway: Deploying a self-hosted Mattermost instance on a KVM VPS for teams up to 250 concurrent users requires a minimum hardware baseline of 2 dedicated vCPUs (%st = 0.0%), 4 GB RAM, 40 GB PCIe 4.0 NVMe storage, and a 1 Gbps uplink operating over TLS 1.3, HTTP/2, and persistent WSS (WebSocket) protocols. To maintain sub-50ms p99 message dispatch latency and eliminate cgroups v2 OOM terminations during sync spikes, configure PostgreSQL 16 with shared_buffers = 1GB, enforce strict container resource constraints in Docker Compose, and optimize the host kernel via sysctl (net.core.somaxconn = 4096 and fs.file-max = 2097152). Terminating SSL at Nginx alongside TCP BBR congestion control ensures deterministic WebSocket multiplexing while isolating the backend Go daemon from socket exhaustion under bursty client reconnection workloads.

Hardware Requirements and Sizing for Mattermost on KVM VPS
Linux Kernel Tuning and Socket Buffers for High-Concurrency WebSockets
Deploying Mattermost Stack with Docker Compose and PostgreSQL 16
Configuring Nginx Reverse Proxy with HTTP/2 and WebSocket Upgrades
LDAP, SSO and Security Hardening for Enterprise Deployments
Automated Backups and Complete Disaster Recovery Runbook
Frequently Asked Questions (FAQ)

Hardware Requirements and Sizing for Mattermost on KVM VPS

Sizing a production-ready mattermost vps self hosted deployment requires modeling resource consumption around the Go runtime scheduler, stateful WebSocket connection counts, and PostgreSQL write-ahead log (WAL) synchronization latency. A Mattermost infrastructure stack comprises three primary subsystems: the Go application server (mattermost-server), the relational database (PostgreSQL 16+), and the storage backend for binary artifacts and file attachments.

Under real-world workloads, resource exhaustion rarely stems from raw message throughput; it is driven by concurrent WebSocket events, database lock contention during multi-channel broadcast fan-outs, and disk I/O bottlenecks when flushing transaction logs to disk.

                              ┌─────────────────────────────────────────┐
                              │           Reverse Proxy / Edge          │
                              │       Nginx / Envoy / TLS 1.3 / BBR     │
                              └────────────────────┬────────────────────┘
                                                   │
                         HTTP/2 REST & WebSockets  │  WSS: /api/v4/websocket
                                                   ▼
                              ┌─────────────────────────────────────────┐
                              │      Mattermost Application Server      │
                              │    Go Runtime (goroutines, epoll)       │
                              │      Bleve / In-Memory Session Cache    │
                              └─────────────┬─────────────┬─────────────┘
                                            │             │
                    SQL Queries / Locks (p99 < 10ms)      │ Object Storage API
                                            │             │ Local / S3 / MinIO
                                            ▼             ▼
┌───────────────────────────────────────────────┐   ┌───────────────────┐
│              PostgreSQL 16+                   │   │    NVMe Storage   │
│  shared_buffers, WAL fsync, autovacuum        │   │  PCIe 4.0 4K QD1  │
└───────────────────────────────────────────────┘   └───────────────────┘

Hypervisor Isolation and CPU Steal Time (%st)

Mattermost relies on Go's M:N work-stealing scheduler (runtime.sched). Active desktop and mobile clients maintain persistent TCP connections via /api/v4/websocket. In a company of 2,000 registered users with 500 concurrent connections, the server handles hundreds of lightweight goroutines managed across available logical cores (GOMAXPROCS).

                CPU Steal Time Impact on Go Work-Stealing Scheduler

   [ Hypervisor CPU Overcommit (Shared Core) ]
   Host Physical Core  ──[ VCPU Steal: 3.5% ]──► Hypervisor Preemption
                                                       │
                                                       ▼
   Go Runtime Scheduler:  Thread M1 Suspended ──► Goroutine G42 Blocked
                                                       │
                                                       ▼
   WebSocket Latency:     p50: 12ms  ──►  p99 Spikes: >850ms (Frame Drops)

In budget or oversubscribed virtual environments, hypervisors overcommit CPU cores across tenants. When physical cores are oversubscribed, the Linux kernel encounters non-zero CPU Steal Time (%st):

$$\text{Steal Time (\%st)} = \frac{\text{Cycles VCPU was ready to run but hypervisor did not allocate physical CPU}}{\text{Total Available Clock Cycles}} \times 100$$

When %st exceeds even $1.0\%-1.5\%$: * The Go runtime's sysmon thread is descheduled unpredictably, causing network poller delays in epoll_wait. * WebSocket message delivery latency p99 degrades from $<15\text{ ms}$ to $>800\text{ ms}$, manifesting as dropped typing indicators, lagging UI reactions, and socket reconnection storms. * PostgreSQL query execution suffers from context-switch delays inside spinlocks (s_lock), triggering transaction timeouts.

To guarantee zero CPU scheduling jitter, run Mattermost exclusively on dedicated KVM instances with dedicated vCPU allocations. On tropic.host KVM instances backed by high-frequency AMD EPYC and Ryzen 9 processors (3.5+ to 4.5+ GHz), hypervisors enforce strict $1:1$ physical-to-virtual CPU mapping. This maintains an audited CPU Steal Time metric of %st = 0.0%, eliminating tail-latency degradation during channel notification cascades.

To monitor for steal time and scheduler anomalies in real time, run:

# Verify steal time (%st) and user/system load per core over 1-second intervals
mpstat -P ALL 1 5

# Check kernel runqueue latency to detect hypervisor context-switch starvation
sar -q 1 5

Memory Sizing and Subsystem Allocation

Mattermost memory allocation scales non-linearly. The application server allocates memory across distinct internal pools: 1. Goroutine Stacks & Network Buffers: Each idle WebSocket connection consumes $\approx 4\text{ to }10\text{ KB}$ for socket buffers and goroutines. Active connections transmitting media previews or typing events allocate dynamic buffers up to $64\text{ KB}$. 2. Channel & Post In-Memory Cache: SqlPostStore and SqlUserStore cache active thread histories to avoid hitting the database for recent messages. A deployment with 500 active channels typically consumes $1.5\text{ to }3\text{ GB}$ of RAM solely for internal LRU caches. 3. Search Indexing: Mattermost includes an embedded Bleve indexing engine for installations without external Elasticsearch. Bleve holds inverted index segments in RAM, adding $1.5\text{ to }4\text{ GB}$ of resident memory overhead depending on attachment and message history depth.

PostgreSQL requires its own dedicated memory allocation on the same host (or on a separated database VPS for $\ge 1,500$ users). Under-allocating RAM leads to Linux OOM-killer invocations, which typically kill PostgreSQL first due to its high resident memory footprint (oom_score_adj).

                    Host Physical RAM Allocation (16 GB Node)

┌──────────────────────┬──────────────────────┬─────────────────────────┐
│   PostgreSQL 16      │   Mattermost Core    │ OS Page Cache & Buffers │
│   shared_buffers     │   Goroutines, Bleve  │ (Kernel networking,     │
│   (4 GB = 25%)       │   LRU Caches (6 GB)  │  dirty pages: 6 GB)     │
└──────────────────────┴──────────────────────┴─────────────────────────┘

Linux Kernel and Memory Optimization (`/etc/sysctl.d/99-mattermost.conf`)

Apply these production kernel parameters to prevent aggressive paging, expand socket queues, and ensure the networking stack handles bursts of WebSocket handshakes:

# Prevent premature swapping while leaving headroom for kernel slab allocations
vm.swappiness = 10
vm.vfs_cache_pressure = 50

# Ensure memory overcommit does not crash PostgreSQL during rapid fork/worker spawns
vm.overcommit_memory = 2
vm.overcommit_ratio = 80

# Expand socket listen backlogs for concurrent WebSocket handshakes
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096

# File descriptor limits for concurrent persistent connections
fs.file-max = 2097152

# Enable BBR TCP congestion control for high-bandwidth media and low p99 latency
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

Apply the configuration immediately:

sysctl --system

NVMe Storage, IOPS, and WAL fsync Latency

Disk I/O latency dictates the maximum throughput of a Mattermost environment. Every message post triggers a synchronous PostgreSQL transaction commit:

$$\text{Transaction Latency} = T_{\text{parse}} + T_{\text{exec}} + T_{\text{WAL flush}} + T_{\text{network}}$$

The critical bottleneck is $T_{\text{WAL flush}}$. PostgreSQL must execute an fsync() system call to flush WAL records from kernel page cache to physical non-volatile media before acknowledging transaction completion to the Mattermost server.

PostgreSQL WAL Transaction Pipeline:
[INSERT INTO Posts] ──► [WAL Buffer in RAM] ──► [fsync() Syscall] ──► [NVMe Controller] ──► [NAND Flash Commit]
                                                        │
                      SATA SSD / Shared SAN:            └─► Sync Latency: 4.5ms - 12ms (Bottleneck)
                      PCIe 4.0 NVMe (tropic.host):      └─► Sync Latency: 0.08ms - 0.15ms (Fast)

On legacy spinning media or shared SAN/SATA virtual disks, fsync latency ranges between $4\text{ ms}$ and $15\text{ ms}$. Under a burst of 100 simultaneous message posts, write locks queue up, resulting in connection pool exhaustion (pq: sorry, too many clients already).

On enterprise NVMe SSDs (PCIe 4.0 with random 4K QD1 read/write $> 50,000\text{ IOPS}$), direct write-through latency is under $150\ \mu\text{s}$ ($0.15\text{ ms}$). This allows a single PostgreSQL instance to sustain over 5,000 transactions per second without blocking the application server thread pool.

Benchmark the underlying disk subsystem using fio to simulate PostgreSQL 8 KB WAL synchronous write behavior:

fio --name=pg-wal-benchmark \
    --filename=/var/lib/postgresql/data/fio_wal_test.dat \
    --size=2G \
    --ioengine=sync \
    --direct=1 \
    --fsync=1 \
    --rw=write \
    --bs=8k \
    --numjobs=1 \
    --group_reporting

Look for clat (completion latency) 99.00th percentile (p99). If $p99 > 2.5\text{ ms}$, the storage layer cannot sustain concurrent channel messaging for teams over 500 users. Hardware platforms on tropic.host run enterprise NVMe arrays with sustained random 4K QD1 performance that keeps WAL flush operations safely below $0.2\text{ ms}$.

Hardware Sizing Matrix (100 to 5,000 Registered Users)

The following capacity matrix defines hardware configurations for KVM VPS deployments. Sizing models assume an active concurrency ratio of $15\%-25\%$ during peak hours, persistent WebSocket telemetry, active desktop screen-sharing sessions (Mattermost Calls / WebRTC), and full-text search.

User Tier (Registered / Concurrent)	Architecture Topology	vCPU Allocation & Specs	RAM (Node Allocation)	Storage Subsystem & IOPS (4K QD1)	Network Interface & Target Latency	Recommended tropic.host Specification
Starter: 100 – 500 users (15 – 100 concurrent)	Single-Node All-In-One • Mattermost Server • PostgreSQL 16 • Local NVMe File Store	4 Dedicated vCPUs AMD EPYC / Ryzen 9 $\ge 3.5\text{ GHz}$, `%st = 0.0%`	8 GB ECC RAM • 3 GB App • 2.5 GB Postgres • 2.5 GB OS/Cache	100 GB NVMe PCIe 4.0 $\ge 25,000\text{ IOPS}$ p99 write $< 0.8\text{ ms}$	1 Gbps Port TCP BBR enabled p99 latency $< 30\text{ ms}$	TR-KVM-4C8G 4 vCPU, 8 GB RAM, 120 GB NVMe, 1 Gbps
Standard: 500 – 1,500 users (100 – 350 concurrent)	Single-Node Optimized • Mattermost Server • PostgreSQL 16 • Redis 7 Cache • Local / MinIO S3 Store	8 Dedicated vCPUs AMD EPYC / Intel Xeon $\ge 3.2\text{ GHz}$, `%st = 0.0%`	16 GB ECC RAM • 6 GB App • 5 GB Postgres • 1 GB Redis • 4 GB OS/Buffers	250 GB NVMe PCIe 4.0 $\ge 45,000\text{ IOPS}$ p99 write $< 0.4\text{ ms}$	1 Gbps Port DDoS protection L3/L4 p99 latency $< 20\text{ ms}$	TR-KVM-8C16G 8 vCPU, 16 GB RAM, 250 GB NVMe, 1 Gbps
Enterprise: 1,500 – 3,000 users (350 – 750 concurrent)	Split Tier (2 Nodes) • Node 1: Mattermost + Redis • Node 2: PostgreSQL 16 Dedicated • Object Storage for Files	16 Dedicated vCPUs (8 vCPU App + 8 vCPU DB) High-frequency $\ge 3.8\text{ GHz}$	32 GB ECC RAM (16 GB App + 16 GB DB) Postgres `shared_buffers = 4GB` `work_mem = 64MB`	500 GB NVMe PCIe 4.0 $\ge 75,000\text{ IOPS}$ p99 write $< 0.2\text{ ms}$	2.5 – 10 Gbps Port Private VLAN interconnect DB $\leftrightarrow$ App latency $< 0.5\text{ ms}$	2x TR-KVM-8C16G (Dedicated App VPS + Dedicated DB VPS)
Scale: 3,000 – 5,000 users (750 – 1,250 concurrent)	Clustered High Availability • 2x Mattermost App Nodes • HA PostgreSQL (Patroni/Primary-Replica) • Redis Sentinel Cluster • Dedicated S3 Bucket	32 Dedicated vCPUs Total • 2x 8 vCPU App Nodes • 1x 16 vCPU DB Node Zero steal time mandatory	64 GB ECC RAM Total • 2x 16 GB App Nodes • 1x 32 GB DB Node Elasticsearch node optional	1 TB+ Enterprise NVMe Hardware RAID 10 NVMe $\ge 100,000\text{ IOPS}$ p99 write $< 0.1\text{ ms}$	10 Gbps Redundant Uplink Multi-region BGP Peering Hardware L7 DDoS filtering	TR-Cluster Custom 3x KVM Instances on AMD EPYC Infrastructure

Production cgroups v2 Limits and Docker Compose Implementation

Running Mattermost via container runtimes without memory and CPU limits invites unconstrained allocations where a single bulk CSV user import or large image thumbnail generation triggers the Linux OOM Killer.

When deploying a mattermost vps self hosted stack on a single KVM VPS (Standard Tier: 8 vCPUs, 16 GB RAM), isolate components using cgroups v2 directives directly in docker-compose.yml:

version: '3.8'

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    volumes:
      - /var/lib/postgresql/data:/var/lib/postgresql/data:Z
    environment:
      POSTGRES_DB: mattermost
      POSTGRES_USER: mmuser
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    deploy:
      resources:
        limits:
          cpus: '4.00'
          memory: 6144M
        reservations:
          cpus: '2.00'
          memory: 4096M
    sysctls:
      - net.core.somaxconn=2048
    command:
      - "postgres"
      - "-c"
      - "shared_buffers=3072MB"
      - "-c"
      - "effective_cache_size=8192MB"
      - "-c"
      - "work_mem=32MB"
      - "-c"
      - "maintenance_work_mem=512MB"
      - "-c"
      - "min_wal_size=1GB"
      - "-c"
      - "max_wal_size=8GB"
      - "-c"
      - "checkpoint_completion_target=0.9"
      - "-c"
      - "wal_buffers=16MB"
      - "-c"
      - "default_statistics_target=100"
      - "-c"
      - "random_page_cost=1.1"

  mattermost:
    image: mattermost/mattermost-team-edition:latest
    restart: unless-stopped
    depends_on:
      - db
    security_opt:
      - no-new-privileges:true
    volumes:
      - /var/opt/mattermost/config:/mattermost/config:Z
      - /var/opt/mattermost/data:/mattermost/data:Z
      - /var/opt/mattermost/logs:/mattermost/logs:Z
      - /var/opt/mattermost/plugins:/mattermost/plugins:Z
      - /var/opt/mattermost/client/plugins:/mattermost/client/plugins:Z
    deploy:
      resources:
        limits:
          cpus: '6.00'
          memory: 7168M
        reservations:
          cpus: '2.00'
          memory: 3584M
    environment:
      MM_SQLSETTINGS_DATASOURCE: "postgres://mmuser:${DB_PASSWORD}@db:5432/mattermost?sslmode=disable&connect_timeout=10"
      MM_SQLSETTINGS_DRIVERNAME: "postgres"
      MM_SQLSETTINGS_MAXIDLECONNS: "30"
      MM_SQLSETTINGS_MAXOPENCONNS: "60"
      MM_SQLSETTINGS_CONNTIMETOLIVEMILLIS: "300000"

In this specification: * The PostgreSQL service is capped at 6144M RAM, with shared_buffers pinned to 3072MB (approximately 25% of available system memory) to maximize hit ratios in shared cache without starving the OS filesystem buffer cache. * random_page_cost is explicitly reduced to 1.1 (down from the default 4.0 for spinning disks), signaling to the query planner that random access occurs across high-throughput NVMe media. This biases the planner toward index scans over sequential disk scans. * The Mattermost application server is provisioned with a soft reservation of 3584M and a ceiling limit of 7168M. This gives the Go runtime sufficient headroom to handle search indexing and memory allocations during bulk uploads without risking systemwide out-of-memory lockups.

Linux Kernel Tuning and Socket Buffers for High-Concurrency WebSockets

While container-level cgroup constraints prevent PostgreSQL and Mattermost from exhausting host memory, high-concurrency real-time collaboration imposes unique stress on the Linux networking subsystem. Mattermost maintains persistent, bidirectional TCP connections via WebSockets (/api/v4/websocket) for push notifications, typing events, presence signals, and direct messaging.

On a default Linux distribution, the kernel is tuned for generic batch workloads and short-lived HTTP request-response cycles. When operating a mattermost vps self hosted setup handling thousands of simultaneous connections, default socket backlogs, connection tracking tables, and buffer allocation policies trigger dropped handshakes (SYN floods), ephemeral port starvation, and EMFILE (Too many open files) panics.

File Descriptor Sizing and Process Caps

Every active WebSocket connection consumes one file descriptor within the reverse proxy (Nginx or Envoy), one file descriptor inside the Mattermost Go server process, and associated socket primitives inside the kernel slab cache. Additionally, persistent connections to PostgreSQL and internal file handles quickly push process consumption past standard system limits.

Standard Debian and Ubuntu server distributions enforce a default soft limit of 1024 file descriptors per non-root process. To eliminate resource starvation:

Update the system-wide limits in /etc/security/limits.d/99-mattermost.conf:

*               soft    nofile          1048576
*               hard    nofile          1048576
root            soft    nofile          1048576
root            hard    nofile          1048576

Because Docker and containerd bypass PAM (limits.conf) when spawned by systemd, enforce process boundaries directly inside the systemd service tree. Create a drop-in override for the Docker daemon at /etc/systemd/system/docker.service.d/override.conf:

[Service]
LimitNOFILE=1048576
LimitNPROC=524288
LimitMEMLOCK=infinity
TasksMax=infinity

Reload the systemd manager configuration and restart the container engine:

systemctl daemon-reload
systemctl restart docker

Validate that the runtime ceiling is recognized by inspecting the live Docker daemon PID:

cat /proc/$(pgrep dockerd)/limits | grep "Max open files"
# Output should reflect: Max open files 1048576 1048576 files

TCP Backlog Queues and Handshake Resiliency

When hundreds of Mattermost desktop and mobile clients reconnect simultaneously following a network blip or an application container reload, the kernel’s connection accept queues saturate within milliseconds. If the backlog queues overflow, the kernel silently drops SYN or ACK packets, forcing clients into exponential TCP backoff cycles that drive p99 connection latencies over 15 seconds.

Three distinct queues govern ingress connection establishment: * net.core.netdev_max_backlog: Determines the maximum number of packets queued on the network interface card (NIC) input ring buffer before being scheduled for processing by the network softirq handler (ksoftirqd). * net.ipv4.tcp_max_syn_backlog: Sets the maximum capacity of half-open TCP connections (uncompleted three-way handshakes awaiting client ACK). * net.core.somaxconn: Dictates the maximum socket listen backlog for fully established connections waiting to be accepted by accept4() in user-space runtimes.

These parameters must be scaled concurrently to prevent bottleneck handoffs:

# Verify current queue drops via netstat/nstat
nstat -az | grep -E "TcpExtListenOverflows|TcpExtListenDrops"

Socket Buffer Architecture: Balancing Concurrency Against RAM

The Linux kernel defaults to aggressive TCP window scaling (net.ipv4.tcp_window_scaling = 1) and dynamic buffer autotuning. For high-throughput single-stream transfers, inflating socket buffers to 4MB or 8MB is desirable. For high-density WebSockets, where payloads consist of lightweight JSON frames (typically under 1.5 KB), unbounded buffer auto-expansion produces catastrophic memory overhead:

$$\text{Memory Overhead} = \text{Active WebSockets} \times (\text{Buffer}{\text{rx}} + \text{Buffer}{\text{tx}} + \text{Slab Structures})$$

If 10,000 idle WebSockets each allocate 256 KB of buffer memory, the kernel consumes over 5 GB of unevictable RAM solely on socket buffers, starving the PostgreSQL buffer pool and invoking the out-of-memory (oom-killer) daemon.

To optimize memory efficiency without bottlenecking bulk channel file attachments, configure the read and write memory vectors (min, default, max) in bytes:

Read buffers (net.ipv4.tcp_rmem): Set a 4 KB minimum to allow small frames, an 8 KB default adequate for WebSocket payloads, and a 2 MB ceiling to preserve throughput for Mattermost file uploads.
Write buffers (net.ipv4.tcp_wmem): Configure an identical 4 KB minimum and 16 KB default to accommodate typical message dispatch cycles while strictly capping peak egress allocations.

Connection State Harvesting and Keepalives

Mobile devices running Mattermost periodically lose connectivity without executing a graceful four-way TCP teardown (FIN/ACK), leaving half-open "zombie" sockets registered on the VPS. These orphaned states consume file descriptors and retain assigned buffer memory until the default 2-hour keepalive timeout expires.

Shrink the TCP keepalive parameters to detect broken peer links within minutes:

net.ipv4.tcp_keepalive_time = 300: Begin sending keepalive probes after 5 minutes of channel inactivity.
net.ipv4.tcp_keepalive_intvl = 15: Space subsequent probes 15 seconds apart.
net.ipv4.tcp_keepalive_probes = 5: Terminate the socket and reclaim resources if the remote client fails to respond to 5 consecutive probes (total teardown latency: 375 seconds).

Congestion Control and Transport Optimization

Deploying modern congestion control algorithms is critical to maintaining consistent p99 interaction latency under network jitter. Google's BBR (Bottleneck Bandwidth and RTT) algorithm models the physical link characteristics rather than treating packet loss as a proxy for congestion. Paired with Fair Queuing (fq), BBR prevents bufferbloat at the edge and accelerates WebSocket event delivery across erratic mobile links.

On standard VPS providers, erratic hypervisor scheduling and CPU overcommitment directly skew kernel RTT calculations, degrading BBR performance and causing sudden packet stalls. Deploying Mattermost on clean KVM virtualization with zero oversubscription—such as tropic.host instances maintaining 0.0% CPU Steal Time (%st = 0.0%) on high-frequency AMD EPYC and Ryzen 9 platforms—ensures that the kernel's network softirqs execute without latency spikes, fully leveraging dedicated 1–10 Gbps uplinks and multi-tier IXP peering routes.

Production Kernel Parameter Configuration

Consolidate these optimizations into a single sysctl configuration file at /etc/sysctl.d/99-mattermost-performance.conf:

# /etc/sysctl.d/99-mattermost-performance.conf
# File descriptor ceilings
fs.file-max = 2097152
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 8192

# Ingress backlogs and socket accept queues
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 16384

# Ephemeral port range and connection recycling
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

# TCP keepalive tuning for dead socket collection
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5

# Socket memory buffers (min, default, max in bytes)
net.ipv4.tcp_rmem = 4096 8192 2097152
net.ipv4.tcp_wmem = 4096 16384 2097152
net.core.rmem_default = 65536
net.core.wmem_default = 65536
net.core.rmem_max = 4194304
net.core.wmem_max = 4194304

# TCP memory limits across all sockets (pages: 4096 bytes)
# Allocates roughly 768MB, 1GB, 1.5GB thresholds
net.ipv4.tcp_mem = 196608 262144 393216

# Connection tracking table capacity (protects stateful netfilter/iptables)
net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_tcp_timeout_established = 86400

# Advanced congestion control and scheduling
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# TCP protocol behavior
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_slow_start_after_idle = 0

Apply the profile immediately across the running kernel:

sysctl --system

Verify that TCP BBR is successfully negotiated by the transport layer:

sysctl net.ipv4.tcp_congestion_control
# Output: net.ipv4.tcp_congestion_control = bbr

lsmod | grep bbr
# Output confirms the tcp_bbr kernel module is loaded

Runtime Audit and Metric Verification

Once the host stack is tuned, audit the network behavior under active client traffic. Inspect socket distribution and memory allocation directly from /proc/net/sockstat:

ss -s

A healthy Mattermost production environment exhibits negligible socket backlogs with memory distributed evenly across active connections:

Total: 3412
TCP:   4210 (estab 3850, closed 210, orphaned 12, timewait 185)

Transport Total     IP        IPv6
RAW   1         1         0        
UDP   8         6         2        
TCP   4000      3950      50       
INET      4009      3957      52       
FRAG      0         0         0

Monitor connection drops in real time to ensure the backlogs are sufficiently provisioned for ingress bursts:

watch -n 1 "netstat -s | grep -i 'listen'"

If times the listen queue of a socket overflowed remains static at 0 during high-volume team communication spikes, the network layer is properly tuned to sustain uninterrupted WebSocket execution without dropping frames or triggering client-side reconnect storms.

Deploying Mattermost Stack with Docker Compose and PostgreSQL 16

With transport-layer buffers stabilized and the network stack verified against socket overflow, deployment transitions to container orchestration. In a production mattermost vps self hosted deployment, reliability depends on deterministic filesystem permissions, strict cgroups v2 resource quotas, and database storage parameters tuned for zero-penalty random I/O.

Directory Scaffolding and Permission Topology

The official Mattermost container image (mattermost/mattermost-team-edition) drops root privileges during entrypoint execution and runs under the dedicated unprivileged user mattermost (UID:GID 2000:2000). PostgreSQL 16 official images execute under UID:GID 999:999.

Bind mounts on the host filesystem must match these numeric IDs prior to container creation to prevent permission faults during initial database bootstrap and local asset writes.

Create the host directory tree under /opt/mattermost:

mkdir -p /opt/mattermost/{config,data,logs,plugins,client-plugins,bleve-indexes}
mkdir -p /opt/mattermost/postgres/data

# Assign deterministic ownership to the service runtimes
chown -R 2000:2000 /opt/mattermost/{config,data,logs,plugins,client-plugins,bleve-indexes}
chown -R 999:999 /opt/mattermost/postgres

# Restrict directory access masks to prevent cross-service leakage
chmod -R 700 /opt/mattermost/postgres
chmod -R 750 /opt/mattermost/{config,data,logs,plugins,client-plugins,bleve-indexes}

On tropic.host KVM instances, these directories map directly to enterprise PCIe 4.0 NVMe arrays operating at random 4K QD1 read/write rates above 50,000 IOPS. Because compute nodes operate with zero CPU oversubscription (%st = 0.0%), local disk operations will not stall behind neighbor contention or shared hypervisor cache flushes, maintaining database fsync execution times well under 0.8 ms.

Environment Variable Definition

Store sensitive credentials and database connection definitions in a locked .env file within /opt/mattermost/.env:

cat << 'EOF' > /opt/mattermost/.env
# Database Settings
POSTGRES_USER=mmuser
POSTGRES_PASSWORD=SECURE_GENERATED_POSTGRES_PASSPHRASE_64CHAR
POSTGRES_DB=mattermost

# Mattermost Core Runtime
MM_SQLSETTINGS_DATASOURCE=postgres://mmuser:SECURE_GENERATED_POSTGRES_PASSPHRASE_64CHAR@postgres:5432/mattermost?sslmode=disable&connect_timeout=10
MM_SERVICESETTINGS_SITEURL=https://chat.example.com
MM_SERVICESETTINGS_LISTENADDRESS=:8065

# Storage Backend (Local NVMe)
MM_FILESETTINGS_DRIVERNAME=local
MM_FILESETTINGS_DIRECTORY=/mattermost/data

# Cluster & Engine Limits
MM_PLUGINSETTINGS_ENABLE=true
MM_PLUGINSETTINGS_ENABLEUPLOADS=true
MM_LOGSETTINGS_ENABLECONSOLE=true
MM_LOGSETTINGS_CONSOLELEVEL=INFO
MM_LOGSETTINGS_CONSOLEJSON=true
EOF

chmod 600 /opt/mattermost/.env

Production `docker-compose.yml`

This manifest configures Mattermost alongside an optimized PostgreSQL 16 container. It isolates the stack inside a private bridge network, establishes continuous health checks to coordinate startup ordering, defines cgroups v2 memory and CPU ceilings, and exposes the HTTP/WebSocket daemon exclusively on the loopback interface (127.0.0.1:8065) for reverse proxy termination.

services:
  postgres:
    image: postgres:16-bookworm
    container_name: mattermost-postgres
    restart: always
    security_opt:
      - no-new-privileges:true
    env_file:
      - /opt/mattermost/.env
    volumes:
      - /opt/mattermost/postgres/data:/var/lib/postgresql/data
      - /etc/localtime:/etc/localtime:ro
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    command: >
      postgres
      -c max_connections=250
      -c shared_buffers=2GB
      -c effective_cache_size=6GB
      -c maintenance_work_mem=512MB
      -c checkpoint_completion_target=0.9
      -c wal_buffers=16MB
      -c default_statistics_target=10
## Deploying Mattermost Stack with Docker Compose and PostgreSQL 16

With network-level socket backlogs fortified against ingress connection bursts, orchestration moves to container provisioning. Running a resilient mattermost vps self hosted architecture demands strict filesystem access controls, explicit cgroups v2 isolation, and a PostgreSQL 16 instance tuned specifically for low-latency concurrent writes.

### Filesystem Layout and Numerical Identity Mapping

Container runtimes should never execute database daemons or web services as unconstrained root processes. The official Mattermost application image executes internally as an unprivileged service account with UID `2000` and GID `2000`. Concurrently, Debian-based PostgreSQL 16 images operate under UID `999` and GID `999`.

To eliminate initialization failures and permission denials during schema generation or file attachment streaming, provision the directory structure on the host before spinning up containers:

```bash
# Provision primary service directories
mkdir -p /srv/mattermost/app/{config,data,plugins,client-plugins}
mkdir -p /srv/mattermost/postgres/data
mkdir -p /srv/mattermost/postgres/conf.d

# Set numerical ownership aligned with internal container namespaces
chown -R 2000:2000 /srv/mattermost/app
chown -R 999:999 /srv/mattermost/postgres

# Restrict permissions against lateral privilege traversal
chmod 750 /srv/mattermost/app
chmod 700 /srv/mattermost/postgres/data

On tropic.host KVM instances, mounting these directories onto dedicated enterprise PCIe 4.0 NVMe arrays delivers direct random 4K I/O performance exceeding 50,000 IOPS. Because the hypervisor enforces hardware-level isolation with zero CPU oversubscription (%st = 0.0%), PostgreSQL disk flushes (fsync) remain deterministic, preventing write-ahead log (WAL) stalls during high-concurrency channel updates.

High-Throughput PostgreSQL 16 Configuration

Rather than relying on default relational settings designed for legacy 512 MB systems, deploy a dedicated configuration profile in /srv/mattermost/postgres/conf.d/01-mattermost.conf. The parameters below target an environment allocated 4 vCPUs and 8 GB of RAM:

# Storage and Memory Allocation
shared_buffers = 2GB
effective_cache_size = 6GB
maintenance_work_mem = 512MB
work_mem = 16MB
wal_buffers = 16MB

# Checkpoint and Disk Sync
min_wal_size = 1GB
max_wal_size = 4GB
checkpoint_completion_target = 0.9
checkpoint_timeout = 15min

# NVMe Storage Latency Profile
random_page_cost = 1.1
effective_io_concurrency = 200

# Worker Scheduling and Connection Limits
max_connections = 180
max_worker_processes = 4
max_parallel_workers_per_gather = 2
max_parallel_maintenance_workers = 2

Setting random_page_cost = 1.1 forces the PostgreSQL planner to leverage NVMe read characteristics, preventing slow sequential table scans on indexed lookups.

Production Container Orchestration Manifest

Construct /srv/mattermost/docker-compose.yml. This manifest decouples the application layer from external public networks, locks down Linux capabilities, enforces cgroups v2 hard limits, and binds HTTP listeners strictly to 127.0.0.1 for upstream TLS termination:

version: '3.8'

services:
  postgres:
    image: postgres:16-bookworm
    container_name: mattermost_db
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - SETUID
      - SETGID
      - DAC_OVERRIDE
    environment:
      POSTGRES_DB: mattermost
      POSTGRES_USER: mmuser
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - /srv/mattermost/postgres/data:/var/lib/postgresql/data
      - /srv/mattermost/postgres/conf.d:/etc/postgresql/conf.d:ro
    command: ["postgres", "-c", "config_file=/etc/postgresql/conf.d/01-mattermost.conf"]
    secrets:
      - db_password
    networks:
      backend_mesh:
        ipv4_address: 172.28.10.2
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U mmuser -d mattermost"]
      interval: 10s
      timeout: 5s
      retries: 5
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4096M
        reservations:
          cpus: '1.0'
          memory: 2048M

  mattermost:
    image: mattermost/mattermost-team-edition:9.11
    container_name: mattermost_app
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    environment:
      MM_SQLSETTINGS_DRIVERNAME: postgres
      MM_SQLSETTINGS_DATASOURCE: postgres://mmuser:${DB_SECRET}@172.28.10.2:5432/mattermost?sslmode=disable&connect_timeout=10
      MM_SERVICESETTINGS_SITEURL: https://collab.internal.domain
      MM_SERVICESETTINGS_LISTENADDRESS: :8065
      MM_FILESETTINGS_DRIVERNAME: local
      MM_FILESETTINGS_DIRECTORY: /mattermost/data
      MM_CLUSTERSETTINGS_ENABLE: "false"
      MM_LOGSETTINGS_ENABLECONSOLE: "true"
      MM_LOGSETTINGS_CONSOLELEVEL: "WARN"
      MM_LOGSETTINGS_CONSOLEJSON: "true"
    volumes:
      - /srv/mattermost/app/config:/mattermost/config
      - /srv/mattermost/app/data:/mattermost/data
      - /srv/mattermost/app/plugins:/mattermost/plugins
      - /srv/mattermost/app/client-plugins:/mattermost/client/plugins
    ports:
      - "127.0.0.1:8065:8065"
    networks:
      backend_mesh:
        ipv4_address: 172.28.10.3
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8065/api/v4/system/ping"]
      interval: 15s
      timeout: 5s
      retries: 4
      start_period: 40s
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 3072M
        reservations:
          cpus: '0.5'
          memory: 1024M

secrets:
  db_password:
    file: /srv/mattermost/db_password.txt

networks:
  backend_mesh:
    driver: bridge
    internal: true
    ipam:
      driver: default
      config:
        - subnet: 172.28.10.0/24

Initializing the Deployment

Generate high-entropy secrets and launch the stack:

# Generate database authentication token
openssl rand -base64 36 | tr -dc 'a-zA-Z0-9' | head -c 32 > /srv/mattermost/db_password.txt
chmod 600 /srv/mattermost/db_password.txt

# Export database credential to environment scope for compose parsing
export DB_SECRET=$(cat /srv/mattermost/db_password.txt)

# Launch isolated daemon services
cd /srv/mattermost
docker compose up -d

Runtime Validation and cgroups v2 Verification

Confirm container health and verify that the Linux kernel successfully bounds runtime execution within the provisioned cgroups v2 slices:

docker compose ps

Both containers must report healthy in the status column:

NAME                IMAGE                                  STATUS                    PORTS
mattermost_app      mattermost/mattermost-team-edition:9.11 Up 2 minutes (healthy)   127.0.0.1:8065->8065/tcp
mattermost_db       postgres:16-bookworm                   Up 2 minutes (healthy)   5432/tcp

Audit memory enforcement directly through the host unified cgroup hierarchy:

# Locate container runtime IDs
APP_CID=$(docker inspect --format '{{.Id}}' mattermost_app)

# Inspect cgroups v2 memory controllers
cat /sys/fs/cgroup/system.slice/docker-${APP_CID}.scope/memory.max
# Output: 3221225472 (Matching the configured 3072M limit)

cat /sys/fs/cgroup/system.slice/docker-${APP_CID}.scope/memory.current

Under steady-state messaging and WebSocket heartbeat exchanges, Mattermost will stabilize between 650 MB and 1.1 GB of Resident Set Size (RSS). PostgreSQL query p99 latency will clock under 1.8 ms on clean KVM hardware, ensuring zero degradation during simultaneous channel joins and search indexing.

Configuring Nginx Reverse Proxy with HTTP/2 and WebSocket Upgrades

With the internal Mattermost application daemon bound to 127.0.0.1:8065, public traffic ingress requires an edge reverse proxy configured for TLS 1.3 termination, HTTP/2 binary multiplexing, and persistent bidirectional stream handshakes. In a production mattermost vps self hosted architecture, Nginx acts as the boundary controller, absorbing connection overhead and shielding Go runtime threads from slow-client attacks.

1. Prerequisite Package Installation and ACME Directory Setup

Install Nginx and the Python-based Certbot ACME client:

apt-get update && apt-get install -y nginx certbot python3-certbot-nginx
systemctl enable --now nginx

Create an isolated directory for Let's Encrypt automated challenge validation:

mkdir -p /var/www/certbot
chown -R www-data:www-data /var/www/certbot
chmod 755 /var/www/certbot

2. Upstream Connection Mapping and Buffer Architecture

Mattermost relies on two distinct traffic profiles: stateless REST API queries/file uploads, and long-lived, stateful WebSocket channels (/api/v4/websocket) for real-time presence and message synchronization.

Standard reverse proxy configurations drop idle connections after 60 seconds (proxy_read_timeout), causing clients to enter continuous reconnect loops that inflate CPU usage and flood PostgreSQL with session lookups. Furthermore, missing Upgrade and Connection headers prevent the initial HTTP/1.1 101 Switching Protocols handshake from succeeding.

Define the connection upgrade mapping in /etc/nginx/conf.d/mattermost_map.conf:

# Map client upgrade requests to establish clean HTTP/1.1 persistent tunnels
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

3. Cryptographic Asset Provisioning

Generate an ephemeral bootstrap configuration to pass the Let's Encrypt HTTP-01 challenge before locking down TLS parameters:

cat <<'EOF' > /etc/nginx/conf.d/acme_bootstrap.conf
server {
    listen 80;
    listen [::]:80;
    server_name chat.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/certbot;
        default_type "text/plain";
        try_files $uri =404;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}
EOF

nginx -t && systemctl reload nginx

Execute Certbot to request a 4096-bit RSA certificate with automated renewal hooks:

certbot certonly --webroot \
    -w /var/www/certbot \
    -d chat.example.com \
    --rsa-key-size 4096 \
    --agree-tos \
    --no-eff-email \
    --email [email protected]

Confirm that Let's Encrypt populated the cryptographic bundle:

ls -la /etc/letsencrypt/live/chat.example.com/
# Expected: cert.pem  chain.pem  fullchain.pem  privkey.pem

Remove the temporary bootstrap file:

rm /etc/nginx/conf.d/acme_bootstrap.conf

4. Production Virtual Host Specification

Deploy the production server block at /etc/nginx/sites-available/mattermost.conf. This configuration implements HTTP/2, strict cipher isolation (TLS 1.2 and TLS 1.3 only), 600-second WebSocket heartbeat windows, large payload handling for binary attachments, and memory-buffered upstream proxying:

upstream mattermost_backend {
    server 127.0.0.1:8065;
    keepalive 64;
}

# Plaintext redirection
server {
    listen 80;
    listen [::]:80;
    server_name chat.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/certbot;
        default_type "text/plain";
        try_files $uri =404;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

# TLS Ingress
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name chat.example.com;

    # Cryptographic materials
    ssl_certificate /etc/letsencrypt/live/chat.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/chat.example.com/privkey.pem;

    # Protocol isolation and cipher suite ordering
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # Session caching and ticket mitigation
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/chat.example.com/chain.pem;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # Security Headers
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;

    # Ingress Sizing Constraints
    client_max_body_size 100M;
    client_body_buffer_size 256k;
    client_body_timeout 60s;

    # Fast memory proxy buffers to avoid disk spill
    proxy_buffers 16 64k;
    proxy_buffer_size 32k;
    proxy_busy_buffers_size 128k;
    proxy_temp_file_write_size 128k;

    # WebSocket Real-Time Gateway
    location ~ /api/v4/websocket {
        proxy_pass http://mattermost_backend;
        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $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_set_header X-Frame-Options SAMEORIGIN;

        # Keepalive timeouts matching Mattermost server-side ping timers
        proxy_connect_timeout 60s;
        proxy_send_timeout 600s;
        proxy_read_timeout 600s;

        # Disable response buffering for zero latency packet dispatch
        proxy_buffering off;
    }

    # Standard Application Delivery
    location / {
        proxy_pass http://mattermost_backend;
        proxy_http_version 1.1;

        proxy_set_header Connection "";
        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_set_header X-Frame-Options SAMEORIGIN;

        proxy_connect_timeout 60s;
        proxy_send_timeout 300s;
        proxy_read_timeout 300s;

        proxy_cache_bypass $http_upgrade;
    }
}

Enable the site configuration and verify syntax:

ln -s /etc/nginx/sites-available/mattermost.conf /etc/nginx/sites-enabled/
rm -f /etc/nginx/sites-enabled/default
nginx -t
systemctl reload nginx

5. Transport Layer Optimization and Hardware Backing

At high concurrency, reverse proxy performance is constrained by transport layer serialization and storage I/O performance. When clients upload 50 MB attachments or multiple media streams concurrently, Nginx uses its local buffer space before writing temporary segments to /var/lib/nginx/body.

Deploying this stack on tropic.host provides the underlying hardware guarantees required to sustain low latency under burst load: * Zero Steal Time (%st = 0.0%): Dedicated KVM execution slices powered by AMD EPYC and high-frequency Xeon cores eliminate micro-stutters during heavy TLS negotiation handshakes. * PCIe 4.0 NVMe Storage: Random 4K QD1 metrics exceeding 50,000 IOPS ensure that proxy disk-spill operations during sudden file upload bursts never induce thread blocking or elevate latency percentiles. * Kernel BBR & Upstream Fabric: Premium 1–10 Gbps uplinks routed through tier-1 European and Asian exchanges (Frankfurt, Amsterdam, Istanbul) allow TCP BBR to maintain wide congestion windows across lossy WAN links without packet collapse.

Verify that TCP BBR is actively handling socket congestion on the host:

sysctl net.ipv4.tcp_congestion_control
# Expected: net.ipv4.tcp_congestion_control = bbr

6. Edge Validation and SSL Verification

Execute a protocol validation check using curl against the public virtual host:

# Validate HTTP/2 negotiation and HSTS enforcement
curl -I --http2 -s https://chat.example.com | grep -E "(HTTP\/2|strict-transport-security|upgrade)"

Output:

HTTP/2 200 
strict-transport-security: max-age=63072000; includeSubDomains; preload

Validate bidirectional WebSocket upgrade mechanics over TLS by crafting a manual protocol switch probe:

curl -i -N \
     -H "Connection: Upgrade" \
     -H "Upgrade: websocket" \
     -H "Host: chat.example.com" \
     -H "Origin: https://chat.example.com" \
     -H "Sec-WebSocket-Key: SGVsbG9Xb3JsZCE=" \
     -H "Sec-WebSocket-Version: 13" \
     https://chat.example.com/api/v4/websocket

The response must return an immediate HTTP status 101 Switching Protocols:

HTTP/1.1 101 Switching Protocols
Server: nginx
Date: Sun, 04 Oct 2026 16:45:00 GMT
Connection: upgrade
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Finally, verify that automated certificate renewal runs smoothly within systemd timers:

certbot renew --dry-run

With the proxy layer operational and cryptographically secured, end-to-end client latency p99 across persistent WebSocket channels will hold below 12 ms on local node routing. The stack is ready for operational administration, disaster recovery pipeline integration, and automated backup scheduling.

LDAP, SSO and Security Hardening for Enterprise Deployments

Securing a mattermost vps self hosted infrastructure requires mitigating risks across three distinct layers: the directory identity boundary, the host packet filtering path, and the container isolation context. Deploying the application behind a reverse proxy is insufficient on its own; unhardened Docker bridge networking allows port exposures that bypass standard firewall chains, and unthrottled authentication endpoints leave directory services vulnerable to distributed credential stuffing.

1. Directory Integration: Secure LDAPS Configuration

Enterprise identity federation offloads credential verification to an authoritative upstream directory service (Active Directory, FreeIPA, or OpenLDAP) while maintaining local role-based access control (RBAC). In high-throughput enterprise environments, directory queries must run strictly over encrypted TLS wrappers (ldaps:// on TCP port 636) with certificate validation enforced at the system truststore.

Within the Mattermost configuration (config.json or injected via MM_LDAPSETTINGS_* environment variables in your container definitions), define directory parameters that eliminate anonymous binds, enforce connection reuse, and map immutable unique object identifiers:

{
  "LdapSettings": {
    "Enable": true,
    "EnableSync": true,
    "LdapServer": "directory.internal.network",
    "LdapPort": 636,
    "ConnectionSecurity": "TLS",
    "BaseDN": "OU=Employees,DC=corp,DC=internal",
    "BindUsername": "CN=svc_mattermost,OU=ServiceAccounts,DC=corp,DC=internal",
    "BindPassword": "EncryptedServiceAccountSecretToken_2026",
    "UserFilter": "(&(objectClass=person)(memberOf=CN=ChatUsers,OU=Groups,DC=corp,DC=internal)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))",
    "FirstNameAttribute": "givenName",
    "LastNameAttribute": "sn",
    "EmailAttribute": "mail",
    "UsernameAttribute": "sAMAccountName",
    "IdAttribute": "objectGUID",
    "PositionAttribute": "title",
    "SyncIntervalMinutes": 60,
    "SkipCertificateVerification": false,
    "QueryTimeout": 20,
    "MaxPageSize": 1000
  }
}

Directory Attribute Mapping Considerations

Immutable Object ID (IdAttribute): Bind IdAttribute to objectGUID (Active Directory) or entryUUID (RFC 4530 / OpenLDAP). Do not map IdAttribute to sAMAccountName or mail; user renames or email updates will fork user profiles and orphan message ownership.
Certificate Chain Validation (SkipCertificateVerification: false): Mount the enterprise internal CA bundle directly into the Mattermost container at /etc/ssl/certs/ca-certificates.crt via a read-only volume mount: ```yaml volumes:
- /etc/ssl/certs/corp-internal-ca.crt:/etc/ssl/certs/corp-internal-ca.crt:ro ```
Synchronization Pressure: A synchronization interval (SyncIntervalMinutes) set below 15 minutes causes unnecessary lock contention inside the PostgreSQL Users table on large enterprise directories (> 5,000 active seats). Keep synchronization scheduled at 60-minute intervals, relying on on-demand authentication checks during initial login handshakes.

2. Network Perimeter Defense and the Docker iptables Bypass Trap

By default, the Docker daemon manipulates iptables and nftables by injecting raw NAT rules directly into the PREROUTING chain. As a result, any container with exposed ports (e.g., -p 5432:5432 or -p 8065:8065) completely bypasses standard host-level firewalls such as ufw or basic INPUT drop policies, exposing sensitive internal daemons to the public IPv4 interface.

To remediate this architectural vulnerability without breaking container bridge routing, all custom packet-filtering rules must be explicitly appended to the DOCKER-USER chain.

Establishing the DOCKER-USER Perimeter Filtering

Create a persistent filtering ruleset in /etc/iptables/rules.v4:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:DOCKER-USER - [0:0]

# 1. State-tracking loopback and established connections
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT

# 2. Host-level SSH access (rate-limited)
-A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --set --name SSH
-A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
-A INPUT -p tcp --dport 22 -j ACCEPT

# 3. Public Web ingress (Nginx edge proxy only)
-A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT

# 4. ICMP Path MTU Discovery handling
-A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/sec -j ACCEPT
-A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT

# 5. DOCKER-USER Chain Hardening: Prevent direct access to internal container ports
# Allow loopback/internal bridge forwarding
-A DOCKER-USER -i docker0 -j ACCEPT
-A DOCKER-USER -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Explicitly drop external packets targeting internal database and app containers
-A DOCKER-USER -i eth0 -p tcp -m multiport --dports 5432,8065,26257 -j DROP

# Default return to process regular Docker forwarding
-A DOCKER-USER -j RETURN

COMMIT

Apply and verify the stateful table without dropping established SSH sessions:

iptables-restore < /etc/iptables/rules.v4
iptables -L DOCKER-USER -v -n

Because cloud instances on tropic.host provide dedicated KVM compute with %st = 0.0% and hardware L3/L4 DDoS filtering at upstream BGP edges, the host kernel can dedicate all packet-inspection cycles to local rate limiting and application-level isolation without drops caused by hypervisor-level CPU throttling.

3. Automated Brute-Force Mitigation with Fail2ban

Distributed dictionary attacks and credential stuffing against /api/v4/users/login generate high application-thread overhead and risk directory account lockouts. Implementing Fail2ban directly against Nginx structured access logs intercepts repeat offenders at the Linux kernel firewall before requests reach the Go runtime.

Step 1: Configure Custom Fail2ban Filter

Create /etc/fail2ban/filter.d/mattermost-auth.conf:

[Definition]
# Match HTTP 401 Unauthorized responses targeting the Mattermost authentication endpoints
failregex = ^<HOST> - .* "(?:POST) /api/v4/users/login(?:/.*)? HTTP/[12]\.[0-9]" 401 .*$
            ^<HOST> - .* "(?:POST) /api/v4/users/login/mfa HTTP/[12]\.[0-9]" 401 .*$

ignoreregex =

Step 2: Configure the Mattermost Jail

Define the jailing policy inside /etc/fail2ban/jail.d/mattermost.local:

[mattermost-auth]
enabled  = true
port     = http,https
filter   = mattermost-auth
logpath  = /var/log/nginx/mattermost_access.log
maxretry = 5
findtime = 300
bantime  = 3600
banaction = iptables-multiport[name=mattermost, port="http,https", protocol=tcp]

Reload the service and verify active monitoring:

systemctl restart fail2ban
fail2ban-client status mattermost-auth

Output:

Status for the jail: mattermost-auth
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/nginx/mattermost_access.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

4. Kernel Attack Surface Reduction and Container Isolation

To prevent privilege escalation, namespace escapes, and packet spoofing inside multi-tenant environments, tune host-level kernel flags using sysctl.

Hardening Host Kernel Parameters

Append the following parameters to /etc/sysctl.d/99-mattermost-security.conf:

# Enforce Reverse Path Filtering to prevent IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Disable ICMP redirect acceptance and emissions
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Protect against SYN flood attacks (SYN Cookies)
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2

# Mitigation against TCP TIME-WAIT assassination (RFC 1337)
net.ipv4.tcp_rfc1337 = 1

# Disable core dumps for setuid binaries to prevent memory leak exposure
fs.suid_dumpable = 0

# Restrict dmesg access to administrative users
kernel.dmesg_restrict = 1

# Restrict BPF execution to privileged processes
kernel.unprivileged_bpf_disabled = 1

# Maximize file descriptor boundaries for high-concurrency WebSocket channels
fs.file-max = 2097152

Commit the parameters to runtime:

sysctl -p /etc/sysctl.d/99-mattermost-security.conf

Hardening the Docker Container Runtime

Running the Mattermost binary as root (UID 0) inside a container breaks isolation boundaries. Enforce unprivileged user execution, read-only root filesystems, and strict Linux capability dropping via Docker Compose:

services:
  mattermost:
    image: mattermost/mattermost-enterprise-edition:10.1
    user: "2000:2000"
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    read_only: true
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=512M
    deploy:
      resources:
        limits:
          cpus: '4.00'
          memory: 8192M
          pids: 400
        reservations:
          cpus: '2.00'
          memory: 4096M

no-new-privileges:true prevents child processes from inheriting additional privileges via SUID/SGID bits.
cap_drop: - ALL strips all root capabilities from the container runtime; only NET_BIND_SERVICE is re-added if binding to privileged ports is strictly required.
read_only: true locks down the underlying container layer. Attackers cannot overwrite application binaries, write crontabs, or download persistence payloads into the container root directory.
pids: 400 enforces cgroups v2 process limiting, stopping fork bombs from exhausting host task structures (/proc/sys/kernel/pid_max).

With the perimeter secured, access controls integrated with upstream enterprise directories, and container execution strictly constrained, the deployment environment satisfies strict enterprise compliance frameworks while maintaining predictable, sub-15ms p99 response times.

Automated Backups and Complete Disaster Recovery Runbook

Hardening container runtimes and kernel boundaries guarantees process isolation, but stateful persistence remains vulnerable to catastrophic host failures, unrecoverable database corruption, and volume truncation. A resilient mattermost vps self hosted architecture demands an atomic, zero-downtime backup pipeline coupled with a deterministic Disaster Recovery (DR) runbook tested for a Recovery Point Objective (RPO) $\le 1$ hour and a Recovery Time Objective (RTO) $\le 15$ minutes.

Executing hot database backups on a live instance introduces sudden disk I/O bursts. On conventional, oversubscribed hypervisors, heavy sequential writes during pg_dump flush dirty pages to disk, causing storage queue depths to spike and driving PostgreSQL transaction p99 latencies well beyond acceptable thresholds. Maintaining consistent sub-15ms p99 query latency during snapshot generation requires underlying enterprise NVMe storage capable of delivering sustained random 4K QD1 throughput exceeding 50,000 IOPS with zero thermal throttling—a baseline guaranteed on tropic.host KVM instances where strict isolation ensures zero hypervisor CPU contention (%st = 0.0%).

1. Host I/O and Dirty Memory Tuning for Hot Backups

Before scheduling hot database dumps and file-level compression, calibrate the Linux Virtual Memory subsystem to prevent massive write bursts from blocking foreground PostgreSQL processes. Add the following parameters to /etc/sysctl.d/99-mattermost-backup.conf:

# Force background kernel pdflush threads to flush dirty pages earlier
vm.dirty_background_ratio = 5

# Hard ceiling on unwritten dirty memory before synchronous write blocking occurs
vm.dirty_ratio = 10

# Increase memory reservation to shield the Mattermost and PostgreSQL daemons
vm.min_free_kbytes = 131072

Apply the runtime parameters immediately:

sysctl -p /etc/sysctl.d/99-mattermost-backup.conf

These parameters prevent large archives from saturating system RAM buffers, ensuring background flushes occur continuously without starving database read queries of I/O cycles.

2. Production Hot Backup Automation Script

Mattermost persistence relies on two distinct elements: 1. The PostgreSQL Database: Holds channels, users, permissions, posts, and post metadata. 2. The Local File Storage Volume (/mattermost/data): Holds uploaded attachments, user avatars, custom emojis, and compliance archives.

Backing up these components sequentially without proper lock coordination risks state drift. The script below performs an atomic PostgreSQL custom-format dump (-Fc) and an incremental tarball of the attachments, applies symmetric AES-256 GPG encryption, computes cryptographic verification digests, and enforces a strict 7-day retention policy.

Create the script at /usr/local/bin/mattermost-backup.sh:

#!/usr/bin/env bash
set -Eeuo pipefail

# -----------------------------------------------------------------------------
# Mattermost Automated Backup Engine
# -----------------------------------------------------------------------------
TIMESTAMP="$(date +'%Y%m%d_%H%M%S')"
BACKUP_DIR="/var/backups/mattermost"
STAGING_DIR="${BACKUP_DIR}/staging_${TIMESTAMP}"
COMPOSE_DIR="/opt/mattermost"
ENV_FILE="${COMPOSE_DIR}/.env"

GPG_PASSPHRASE_FILE="/etc/mattermost/backup.key"
RETENTION_DAYS=7

# Source environment variables for credentials
if [[ ! -f "${ENV_FILE}" ]]; then
    echo "[!] Critical: Environment configuration ${ENV_FILE} not found." >&2
    exit 1
fi
source "${ENV_FILE}"

mkdir -p "${STAGING_DIR}"
chmod 700 "${BACKUP_DIR}" "${STAGING_DIR}"

cleanup() {
    local exit_code=$?
    if [[ -d "${STAGING_DIR}" ]]; then
        rm -rf "${STAGING_DIR}"
    fi
    exit ${exit_code}
}
trap cleanup EXIT ERR INT TERM

echo "[*] [${TIMESTAMP}] Initiating Mattermost stateful backup..."

# 1. Hot PostgreSQL Dump using custom compressed format (zero read locks)
echo "[*] Dumping PostgreSQL database '${POSTGRES_DB}'..."
docker compose -f "${COMPOSE_DIR}/docker-compose.yml" exec -T db \
    pg_dump -U "${POSTGRES_USER}" -d "${POSTGRES_DB}" \
    -Fc --no-owner --no-privileges --compress=6 \
    > "${STAGING_DIR}/mattermost_db_${TIMESTAMP}.dump"

# 2. Archive File Attachments and Configuration State
echo "[*] Archiving data directory and configuration..."
tar -cpf "${STAGING_DIR}/mattermost_data_${TIMESTAMP}.tar" \
    -C "${COMPOSE_DIR}" volumes/app/mattermost/data config/config.json

# 3. Create Combined Compressed Tarball
ARCHIVE_NAME="mattermost_backup_${TIMESTAMP}.tar.gz"
tar -czpf "${STAGING_DIR}/${ARCHIVE_NAME}" -C "${STAGING_DIR}" \
    "mattermost_db_${TIMESTAMP}.dump" \
    "mattermost_data_${TIMESTAMP}.tar"

# Remove intermediate unencrypted dump files
rm -f "${STAGING_DIR}/mattermost_db_${TIMESTAMP}.dump" "${STAGING_DIR}/mattermost_data_${TIMESTAMP}.tar"

# 4. Symmetrically Encrypt Backup via AES-256
echo "[*] Encrypting archive with GPG (AES-256)..."
ENCRYPTED_ARCHIVE="${BACKUP_DIR}/${ARCHIVE_NAME}.gpg"
gpg --batch --yes --symmetric --cipher-algo AES256 \
    --passphrase-file "${GPG_PASSPHRASE_FILE}" \
    --output "${ENCRYPTED_ARCHIVE}" \
    "${STAGING_DIR}/${ARCHIVE_NAME}"

# 5. Generate Cryptographic Integrity Digest
echo "[*] Calculating SHA-256 checksum..."
cd "${BACKUP_DIR}"
sha256sum "$(basename "${ENCRYPTED_ARCHIVE}")" > "${ENCRYPTED_ARCHIVE}.sha256"

# 6. Apply Local Retention Policy
echo "[*] Pruning local backups older than ${RETENTION_DAYS} days..."
find "${BACKUP_DIR}" -maxdepth 1 -type f -name "mattermost_backup_*.gpg*" -mtime "+${RETENTION_DAYS}" -delete

echo "[+] [${TIMESTAMP}] Backup completed successfully: ${ENCRYPTED_ARCHIVE}"

Generate the encryption key and enforce strict filesystem permissions:

mkdir -p /etc/mattermost /var/backups/mattermost
openssl rand -base64 32 > /etc/mattermost/backup.key
chmod 600 /etc/mattermost/backup.key
chmod 700 /usr/local/bin/mattermost-backup.sh

3. Execution Isolation via Systemd Timer and cgroups v2

Never rely on raw cron for resource-heavy operations. Running backups through a systemd service exposes granular execution control via cgroups v2, preventing unexpected memory expansion or runaway I/O from destabilizing the live Mattermost stack.

Create the service unit at /etc/systemd/system/mattermost-backup.service:

[Unit]
Description=Automated Mattermost Backup and Snapshot Engine
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/mattermost-backup.sh
User=root
StandardOutput=journal
StandardError=journal

# Cgroups v2 Resource Throttling
CPUWeight=20
IOWeight=20
MemoryHigh=2048M
MemoryMax=3072M

Create the companion timer unit at /etc/systemd/system/mattermost-backup.timer:

[Unit]
Description=Nightly Trigger for Mattermost Backup Service

[Timer]
OnCalendar=*-*-* 03:00:00 UTC
Persistent=true
RandomizedDelaySec=600

[Install]
WantedBy=timers.target

Enable and initiate the timer:

systemctl daemon-reload
systemctl enable --now mattermost-backup.timer

Verify timer status and execution schedule:

systemctl list-timers mattermost-backup.timer

4. Step-by-Step Disaster Recovery (DR) Runbook

This runbook covers a total site failure scenario. We execute the restore process onto a cold-standby or freshly deployed tropic.host KVM instance featuring PCIe 4.0 NVMe storage, ensuring parallelized database restoration finishes without storage lockups.

Disaster Recovery Workflow:

[Encrypted Archive] ──> [SHA-256 Check] ──> [GPG Decrypt] ──> [Extract Dump & Data]
                                                                        │
    ┌───────────────────────────────────────────────────────────────────┘
    ▼
[Database Ingestion] ────> [Volume Tree Placement] ───> [Daemon Boot] ───> [Health Check]
(pg_restore -j $(nproc))   (UID:GID 2000:2000)          (Docker Up)        (HTTP /api/v4/ping)

Step 4.1: Target Host Provisioning and Tooling

Install container runtimes and cryptographic tooling on the clean host instance:

apt-get update && apt-get install -y --no-install-recommends \
    docker.io \
    docker-compose-v2 \
    gnupg \
    tar \
    curl \
    coreutils

# Create target orchestration and backup directories
mkdir -p /opt/mattermost /var/backups/mattermost /etc/mattermost

Step 4.2: Retrieve and Verify Archive Integrity

Securely transfer the target encrypted archive, its SHA-256 checksum file, and the decryption key to the clean instance via scp or an out-of-band management pipeline:

# Verify integrity prior to archive extraction
cd /var/backups/mattermost
sha256sum -c mattermost_backup_20261004_030000.tar.gz.gpg.sha256

The output must return OK. If the digest fails, abort execution; corrupted archives will break the relational state of the database.

Step 4.3: Decrypt and Unpack Staging Artifacts

# Decrypt the encrypted payload
gpg --batch --yes --decrypt \
    --passphrase-file /etc/mattermost/backup.key \
    --output /var/backups/mattermost/restoration_payload.tar.gz \
    mattermost_backup_20261004_030000.tar.gz.gpg

# Extract internal dump components
mkdir -p /var/backups/mattermost/restore
tar -xzpf /var/backups/mattermost/restoration_payload.tar.gz -C /var/backups/mattermost/restore

Confirm that the staging directory contains: * mattermost_db_*.dump (PostgreSQL custom format dump) * mattermost_data_*.tar (Storage attachments and system configuration)

Step 4.4: Prepare the Deployment Stack

Deploy your production docker-compose.yml and .env specifications into /opt/mattermost/. Bring up only the PostgreSQL database service to initiate the schema restoration:

cd /opt/mattermost
docker compose up -d db

# Poll database accessibility until ready
until docker compose exec -T db pg_isready -U "${POSTGRES_USER}" -d "${POSTGRES_DB}"; do
    echo "[*] Waiting for PostgreSQL daemon socket readiness..."
    sleep 2
done

Step 4.5: Database Hydration with Parallel Workers

Drop any pre-seeded default databases and execute pg_restore using multiple concurrent worker threads matching host vCPU availability. On high-performance NVMe storage, multithreaded index rebuilding scales near-linearly:

RESTORE_DUMP=$(ls /var/backups/mattermost/restore/mattermost_db_*.dump)

echo "[*] Flushing pre-existing tables and ingesting snapshot..."
docker compose exec -T db dropdb --if-exists -U "${POSTGRES_USER}" "${POSTGRES_DB}"
docker compose exec -T db createdb -U "${POSTGRES_USER}" -O "${POSTGRES_USER}" "${POSTGRES_DB}"

# Pipe dump file through pg_restore using all available vCPU threads
cat "${RESTORE_DUMP}" | docker compose exec -T db \
    pg_restore -U "${POSTGRES_USER}" -d "${POSTGRES_DB}" \
    --clean --if-exists --no-owner --no-privileges \
    -j "$(nproc)"

Note: pg_restore exits with code 1 if non-critical warnings (such as ignoring procedural extension ownership) occur. Inspect output lines to verify all transaction commits succeed.

Step 4.6: Storage Volume Restoration and Permission Alignment

Extract the data volume and enforce strict UID/GID 2000:2000 mapping matching the unprivileged runtime container user configured in the application Dockerfile:

RESTORE_DATA=$(ls /var/backups/mattermost/restore/mattermost_data_*.tar)

# Extract directly into the live Compose root structure
tar -xpf "${RESTORE_DATA}" -C /opt/mattermost/

# Enforce precise Linux DAC permission boundaries
chown -R 2000:2000 /opt/mattermost/volumes/app/mattermost/data
chmod 700 /opt/mattermost/volumes/app/mattermost/data
chmod 600 /opt/mattermost/config/config.json

Step 4.7: Cold-Start Deployment and Health Verification

Spin up the remaining services, including the application daemon and edge reverse proxy:

docker compose up -d

Monitor live application initialization logs:

docker compose logs -f mattermost

Execute an automated healthcheck against the loopback interface to confirm database migration state, schema integrity, and WebSocket subsystem readiness:

# Validate internal application health ping
curl -sSf http://127.0.0.1:8065/api/v4/system/ping | grep -q '{"status":"OK"}' && \
    echo "[+] System Healthcheck Passed: API and Database communication functional." || \
    echo "[-] System Healthcheck Failed: Inspect container journal logs."

Verify WebSocket connection establishment:

curl -i -N -H "Connection: Upgrade" \
     -H "Upgrade: websocket" \
     -H "Sec-WebSocket-Version: 13" \
     -H "Sec-WebSocket-Key: SGVsbG8sIHdvcmxkIQ==" \
     http://127.0.0.1:8065/api/v4/websocket

An immediate response containing HTTP/1.1 101 Switching Protocols confirms that connection upgrades, authentication layers, and network routing have returned to nominal production thresholds. Wipe ephemeral decryption artifacts from the host to conclude the recovery process:

rm -rf /var/backups/mattermost/restore /var/backups/mattermost/restoration_payload.tar.gz

Frequently Asked Questions (FAQ)

How much RAM does Mattermost need on a VPS?

For teams up to 100 active users, a 2 vCPU and 4 GB RAM KVM VPS is sufficient. Larger organizations with 1,000+ active connections require 4–8 vCPU and 8–16 GB RAM with dedicated NVMe storage.

Why is KVM virtualization required for Mattermost?

KVM provides dedicated kernel memory and 0% CPU Steal Time, preventing PostgreSQL query slowdowns and WebSocket disconnections common on overcommitted OpenVZ/LXC hosts.

Back to Blog

How to Self-Host Mattermost on a KVM VPS with Docker Compose, PostgreSQL and Nginx SSL

Table of Contents

Hardware Requirements and Sizing for Mattermost on KVM VPS

Hypervisor Isolation and CPU Steal Time (%st)

Memory Sizing and Subsystem Allocation

Linux Kernel and Memory Optimization (/etc/sysctl.d/99-mattermost.conf)

NVMe Storage, IOPS, and WAL fsync Latency

Hardware Sizing Matrix (100 to 5,000 Registered Users)

Production cgroups v2 Limits and Docker Compose Implementation

Linux Kernel Tuning and Socket Buffers for High-Concurrency WebSockets

File Descriptor Sizing and Process Caps

TCP Backlog Queues and Handshake Resiliency

Socket Buffer Architecture: Balancing Concurrency Against RAM

Connection State Harvesting and Keepalives

Congestion Control and Transport Optimization

Production Kernel Parameter Configuration

Runtime Audit and Metric Verification

Deploying Mattermost Stack with Docker Compose and PostgreSQL 16

Directory Scaffolding and Permission Topology

Environment Variable Definition

Production docker-compose.yml

High-Throughput PostgreSQL 16 Configuration

Production Container Orchestration Manifest

Initializing the Deployment

Runtime Validation and cgroups v2 Verification

Configuring Nginx Reverse Proxy with HTTP/2 and WebSocket Upgrades

1. Prerequisite Package Installation and ACME Directory Setup

2. Upstream Connection Mapping and Buffer Architecture

3. Cryptographic Asset Provisioning

4. Production Virtual Host Specification

5. Transport Layer Optimization and Hardware Backing

6. Edge Validation and SSL Verification

LDAP, SSO and Security Hardening for Enterprise Deployments

1. Directory Integration: Secure LDAPS Configuration

Directory Attribute Mapping Considerations

2. Network Perimeter Defense and the Docker iptables Bypass Trap

Establishing the DOCKER-USER Perimeter Filtering

3. Automated Brute-Force Mitigation with Fail2ban

Step 1: Configure Custom Fail2ban Filter

Step 2: Configure the Mattermost Jail

4. Kernel Attack Surface Reduction and Container Isolation

Hardening Host Kernel Parameters

Hardening the Docker Container Runtime

Automated Backups and Complete Disaster Recovery Runbook

1. Host I/O and Dirty Memory Tuning for Hot Backups

2. Production Hot Backup Automation Script

3. Execution Isolation via Systemd Timer and cgroups v2

4. Step-by-Step Disaster Recovery (DR) Runbook

Step 4.1: Target Host Provisioning and Tooling

Step 4.2: Retrieve and Verify Archive Integrity

Step 4.3: Decrypt and Unpack Staging Artifacts

Step 4.4: Prepare the Deployment Stack

Step 4.5: Database Hydration with Parallel Workers

Step 4.6: Storage Volume Restoration and Permission Alignment

Step 4.7: Cold-Start Deployment and Health Verification

Frequently Asked Questions (FAQ)

How much RAM does Mattermost need on a VPS?

Why is KVM virtualization required for Mattermost?

Linux Kernel and Memory Optimization (`/etc/sysctl.d/99-mattermost.conf`)

Production `docker-compose.yml`