Size your deployment
Pick your scale tier, deployment type, and hosting provider. The builder below renders a target architecture and a bill of materials sized to those choices. Sizing follows the Mattermost scaling guide; provider SKUs are illustrative — verify against current pricing and regional / compliance constraints before committing to a procurement decision.
Bill of materials
| Component | Quantity | Recommended size / SKU | Notes |
|---|---|---|---|
| Load balancer | 1 | AWS Application Load Balancer | TLS terminated at the proxy. Mattermost behind, listening on HTTP/8065. |
| Mattermost app server | 2 nodes | m5.2xlarge (8 vCPU / 32 GB RAM) | High availability — restarts and upgrades are non-disruptive. |
| PostgreSQL (primary) | 1 | Amazon RDS (PostgreSQL) — db.m5.xlarge | Separate host. PostgreSQL 14 minimum. App connects on TCP/5432. |
| PostgreSQL read replicas | 1 | Amazon RDS (PostgreSQL) read replica | Read queries (search, dashboards) offloaded from the primary. |
| Search index | 1 node | Amazon OpenSearch | Recommended — message search performance degrades on the DB alone at this scale. App connects on HTTPS/9200. |
| File storage | — | Amazon S3 | S3-compatible bucket. App connects on HTTPS/443. Backup + versioning recommended. |
| Push notification proxy | 1 | Mattermost Push Proxy (open source) — small single host (1 vCPU / 2 GB) or container | Mediates APNs (api.push.apple.com) and FCM (fcm.googleapis.com) on HTTPS/443. Use HPNS instead if you can reach Mattermost-managed; self-host for air-gapped / sovereign deployments. |
Network flows
Every connection in the architecture above — useful when configuring firewall rules, security groups, or a CAP. Inbound = from clients; internal = within the deployment boundary; egress = out to external services.
| From | To | Direction | Protocol | Port | Purpose |
|---|---|---|---|---|---|
| Web / Desktop / Mobile clients | Load balancer | inbound | HTTPS + WSS | TCP/443 | Channels API, WebSocket events, file uploads |
| Load balancer | Mattermost | internal | HTTP | TCP/8065 | TLS-terminated app traffic |
| Mattermost | PostgreSQL (Amazon RDS (PostgreSQL)) | internal | TCP | 5432 | Database queries |
| Mattermost | OpenSearch (Amazon OpenSearch) | internal | HTTPS | 9200 | Message search index reads + writes |
| Mattermost | Object storage (Amazon S3) | internal | HTTPS | TCP/443 | File uploads, plugin assets, compliance exports |
| Mattermost | Mattermost Push Proxy (self-hosted) | internal | HTTPS | TCP/443 | Push notification submission |
| Mattermost Push Proxy | Apple APNs (api.push.apple.com) | egress | HTTPS | TCP/443 | iOS push fan-out |
| Mattermost Push Proxy | Google FCM (fcm.googleapis.com) | egress | HTTPS | TCP/443 | Android push fan-out |
Sizing follows the Mattermost scaling guide; provider SKUs are illustrative starting points. Verify against current pricing, regional availability, and any compliance constraints before procurement.
How to use this page
- Pick the scale tier that fits your expected concurrent user count. Tiers correspond to the named bands in the scaling guide (Trial / Small / Medium / Large / Extra Large / Mega / Hyperscale).
- Pick a deployment type:
- Virtual machines — Mattermost installed via the Linux install paths, with a separate VM per role (app, database, cache, search). Most common for self-hosted and private-cloud deployments.
- Kubernetes — Mattermost deployed via the Mattermost Operator. The diagram and bill of materials swap the load balancer for an ingress controller and the app row for the Operator pattern.
- Pick a hosting provider to see provider-specific SKU recommendations. On-prem / Other swaps managed services for self-managed equivalents (PostgreSQL on a VM, Redis on a VM, OpenSearch / Elasticsearch on a VM cluster, MinIO or NFS for object storage).
What's next
Once you've sized the architecture:
- For air-gapped environments, also work through Air-Gapped Operations. The architecture is the same; the install procedure and dependency-staging are different.
- For HA tuning (clustering, Redis configuration, multi-AZ database topology), see High Availability cluster-based deployment.
- For version and hardware minimums on the components you just sized, see Software and hardware requirements, the last step in Plan.
- To choose an install path, see Deploy the Mattermost server, which compares Kubernetes, Linux, and containers.
This is the second step in Plan, after Application architecture. If you haven't picked the shape of the deployment yet, Deployment Scenarios covers which operational pattern fits (air-gapped, mission partner, DDIL, sovereign-Microsoft, out-of-band); this page sizes the components of whichever shape you pick.