More simultaneous messaging, integrations and API traffic can push CPU and RAM above the published 1–2,000-user single-server tiers.
Teams with high concurrency despite a modest registered-user count.Wymagania sprzętowe Mattermost: pamięć RAM, procesor, pamięć masowa i liczba użytkowników
Porównaj wymagania sprzętowe Mattermost dla 1–1000 i 1000–2000 użytkowników, a także PostgreSQL, pamięć na pliki oraz praktyczny dobór rozmiaru niestandardowej instalacji ZimaOS.
Mattermost requirements at a glance
Mattermost's current hardware guide gives explicit CPU/RAM recommendations for small-to-medium team deployments and warns that storage and memory can vary substantially with user behavior and file sharing.
- 1–1,000 users
- Official team recommendation: 1 vCPU/core and 2 GB RAM on a single server.
- 1,000–2,000 users
- Official team recommendation: 2 vCPU/cores and 4 GB RAM on a single server.
- Storage
- No universal numerical disk minimum in the hardware table. File sharing, PostgreSQL growth, search data and backups determine capacity.
- File sharing
- Mattermost notes that memory requirements can be driven by peak file-sharing activity; its sizing assumption uses the default 50 MB maximum file size.
- GPU
- No GPU is required for core Mattermost messaging, channels, file sharing or normal search workloads.
- Best Zima starting point
- ZimaBoard 2 832 easily exceeds the 1–2,000-user CPU/RAM guidance on paper; ZimaBoard 2 1664 or ZimaCube 2 Pro adds room for PostgreSQL, search, monitoring and other co-hosted services.
From official requirements to the right setup
Mattermost sizing starts with registered users and actual activity, then adds PostgreSQL, file-sharing peaks, search, backups and any enterprise monitoring/search services.
-
Official requirements
Use Mattermost's official team tiers as the baseline: 1 vCPU/2 GB RAM for 1–1,000 registered users and 2 vCPU/4 GB RAM for 1,000–2,000.
-
Confirm your needs
Adjust for real user behavior. Peak file sharing, concurrent activity and integration traffic can raise memory and storage demand above the simple registered-user tiers.
-
Leave room to grow
Plan PostgreSQL and file storage separately. Database growth, attachments, backups and optional enterprise search can become the main bottlenecks long before the core app reaches its CPU/RAM ceiling.
-
Run it on ZimaOS
On ZimaOS, use Install Custom App with Mattermost's Docker Compose path for evaluation/testing or a carefully managed self-hosted deployment. Persist PostgreSQL and Mattermost data, configure HTTPS and storage, and recognize that Mattermost does not support Docker Compose for production HA.
Check every playback client
- Registered users and active concurrency
- Peak file-sharing behavior
- PostgreSQL persistence and growth
- Local, NFS or S3-compatible file storage
- Search requirements and Elasticsearch/OpenSearch
- Monitoring with Prometheus/Grafana
- HTTPS and reverse-proxy configuration
- Production HA or evaluation/small-team use
Official minimum requirements
Mattermost publishes small-team hardware recommendations by registered-user count, while explicitly stating that CPU, RAM and storage can vary significantly with user behavior.
For a small team, the official 1 vCPU/2 GB tier is a legitimate upstream recommendation. Do not turn it into a storage guarantee or assume 2 GB remains sufficient when file sharing, PostgreSQL, search, monitoring and other ZimaOS apps share the host.
| Requirement | Official minimum | What this supports |
|---|---|---|
| 1–1,000 registered users | 1 vCPU/core, 2 GB RAM | Official single-server team deployment recommendation. |
| 1,000–2,000 registered users | 2 vCPU/cores, 4 GB RAM | Official single-server team deployment recommendation. |
| Processor architecture | 64-bit x86 | Mattermost states support for 64-bit x86 processor architecture in the current requirements guide. |
| Storage minimum | No universal numerical minimum published in the hardware table | Storage varies with file uploads, database growth, backups and optional search/object storage. |
| File-sharing sizing assumption | Default 50 MB maximum file size | Mattermost warns that changing file-size limits can change memory requirements. |
| >2,000 users | Pilot/load-test before scale-out | Mattermost recommends its load-testing framework for larger deployments rather than extrapolating the small-team table. |
| Database direction | PostgreSQL preferred | Current docs say MySQL support is being deprecated starting with Mattermost v11. |
When to upgrade your hardware
Mattermost should scale when activity, file sharing or database/search services outgrow the small-team hardware tier, not simply when another account is created.
Active usage exceeds the small-team profile
File sharing creates memory or storage pressure
Search and monitoring become separate services
Mattermost explicitly warns that peak file-sharing activity can drive memory requirements, while attachments and backups consume persistent storage.
Teams sharing large files or increasing the default upload limit.Enterprise-scale Mattermost can add Elasticsearch/OpenSearch, Prometheus and Grafana, turning a simple app server into a multi-service infrastructure stack.
Organizations moving toward enterprise search, observability and multi-server operation.Plan hardware growth with confidence
Scale Mattermost by keeping PostgreSQL and file storage healthy, then separate search/monitoring and application roles as the deployment grows.
Keep PostgreSQL on reliable SSD-backed storage
Messaging metadata, posts and search state are database-centric, so predictable database I/O protects user-facing latency.
Use added SATA/NVMe storage on ZimaBoard 2 or SSD tiers in ZimaCube 2 rather than relying only on onboard eMMC.Use object storage for growing file uploads
Mattermost supports S3-compatible object storage as well as local or NFS-based storage, which can reduce pressure on the application server's local disk.
Use ZimaCube 2 for large local storage or move attachments to an external S3-compatible target.Add memory for database, search and co-hosted apps
The 2–4 GB team tiers describe Mattermost itself, not a large all-in-one ZimaOS stack. Additional RAM helps PostgreSQL, monitoring and optional search coexist.
ZimaBoard 2 1664 offers a simple 16 GB compact tier; ZimaCube 2 Pro adds stronger CPU and storage options.Move to multi-server architecture above small-team scale
Mattermost recommends piloting and load testing for deployments above 2,000 users and provides separate enterprise scaling guidance.
Use additional application/database/search systems only after validating real workload and HA design.Can it run on ZimaOS?
Mattermost is not currently presented in the public ZimaOS hardware catalog as a one-click ZimaOS App Store app. It can still be deployed through Install Custom App using Mattermost's official container setup, with an important caveat: Docker Compose is supported for evaluation/testing rather than production high availability.
Custom install Mattermost in ZimaOS
Use Install Custom App with an adapted Mattermost Compose setup, persist Mattermost and PostgreSQL data, configure HTTPS and file storage, and verify ports and secrets before inviting users.
Custom install Mattermost in the ZimaOS app ↗Treat Docker Compose as evaluation/small-scale deployment
Mattermost's current deployment guide says container deployments are for evaluation, testing and development and are not supported for production HA because Docker Compose lacks automatic failover, shared storage and load balancing.
Review Mattermost deployment methods ↗Use PostgreSQL and plan storage deliberately
Mattermost's current requirements favor PostgreSQL as MySQL support is being deprecated, and file storage can be local, NFS or S3-compatible depending on scale.
Review Mattermost software and hardware requirements ↗Choose Zima hardware for Mattermost
Mattermost's published small-team CPU/RAM requirements are modest enough for ZimaBoard 2. Hardware selection becomes more about PostgreSQL, file storage, search and broader server consolidation than the core messaging process.
Is this a small team instance or a broader collaboration platform with search, storage and monitoring services?
Small team or evaluation deployment
ZimaBoard 2 832 is far above Mattermost's 1–2,000-user RAM/core guidance on paper and leaves room for PostgreSQL and light companion services.
- Best compact starting pointZimaBoard 2 832
- More consolidation headroomZimaBoard 2 1664
Larger file/search/database workload
Use stronger CPU, more SSD/HDD expansion and faster networking, while recognizing that >2,000 users and production HA call for load testing and multi-server architecture.
- Storage-first platformZimaCube 2 Standard
- Higher-headroom platformZimaCube 2 Pro
These are workload-based recommendations, not guaranteed user-count or message-throughput benchmarks. Active concurrency, file uploads, database size, search, plugins/integrations, monitoring and other ZimaOS applications can change resource use.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Small Mattermost teams, private communities and evaluation environments. | Mattermost, PostgreSQL, HTTPS proxy, backups and light integrations on one host. |
|
Add SSD storage for PostgreSQL and persistent Mattermost data. User-count guidance assumes traditional deployments and does not guarantee performance under heavy file sharing or integrations. | Get Now |
| ZimaBoard 2 1664 | Mattermost plus more integrations, monitoring or other ZimaOS apps. | Larger PostgreSQL cache, more file activity, monitoring and additional containers. |
|
Extra RAM is whole-host headroom, not evidence that one compact server is appropriate for enterprise HA or >2,000 users. | Get Now |
| ZimaCube 2 Standard | Mattermost with larger local file retention and broader collaboration storage. | Messaging plus PostgreSQL, file uploads, backups and other team services with multi-drive capacity. |
|
Choose Standard mainly for storage expansion; its 8 GB RAM may be less attractive than 16 GB options when search, monitoring and many containers share the host. | Get Now |
| ZimaCube 2 Pro | A heavier Mattermost collaboration host with more database, search and storage demand. | Mattermost, PostgreSQL, monitoring, search integrations, backups and multiple business services. |
|
A stronger single server still does not provide Mattermost production HA. Larger deployments should follow the vendor's multi-server and load-testing guidance. | Get Now |
What the Press Says
Highlights from trusted reviewers worldwide.
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”Read full review
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”Read full review
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”Read full review
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”Read full review
Loved by the Community
Stories and reviews from people who build with Zima every day.
★★★★★
Zima Blade Little yet Powerful
Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.
★★★★★
Very good!!
I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.
★★★★★
Great innovation for mini server!
It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.
★★★★★
Avaliação ZimaBoard 2
Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.
Frequently asked questions
These answers cover Mattermost RAM, CPU, storage, PostgreSQL, file sharing and ZimaOS deployment using the current official team-sizing table.
How much RAM does Mattermost need?
Mattermost recommends 2 GB RAM for 1–1,000 registered users and 4 GB RAM for 1,000–2,000 users on a single-server team deployment. Real usage can be higher when file sharing, integrations, search or other services are heavy.
How many CPU cores does Mattermost need?
The official team table recommends 1 vCPU/core for 1–1,000 registered users and 2 vCPU/cores for 1,000–2,000 users.
How much storage does Mattermost need?
The current hardware table does not publish one universal disk minimum. Size storage for PostgreSQL, attachments, backups, logs and optional search indexes. File retention and upload limits can dominate capacity.
Does Mattermost require PostgreSQL?
PostgreSQL is the preferred current database direction. Mattermost's documentation says MySQL support is being deprecated starting with Mattermost v11.
Does Mattermost need an SSD?
SSD is not expressed as a universal formal minimum in the team sizing table, but SSD-backed PostgreSQL and application data are a strong practical choice for predictable messaging and database latency.
Does Mattermost need a GPU?
No dedicated GPU is required for normal Mattermost messaging, file sharing, channels or standard search. CPU, RAM, PostgreSQL performance and persistent storage are the important hardware dimensions.
Can ZimaBoard 2 run Mattermost?
Yes. Even the 8 GB ZimaBoard 2 exceeds Mattermost's published 1–2,000-user CPU/RAM team tiers on paper. Add SSD storage for PostgreSQL and files, and do not treat the small-team table as a production-HA guarantee.
Can I run production Mattermost with Docker Compose on ZimaOS?
Mattermost's current deployment guide says Docker Compose is for evaluation, testing and development and is not supported for production high availability. A ZimaOS custom install is therefore best framed as small-scale/self-managed use rather than enterprise HA.
What sources informed this Mattermost hardware guide?
The guide uses Mattermost's current hardware requirements and deployment-method documentation for user tiers, architecture and Docker limitations. Current Zima product pages are used only for Zima hardware specifications.
