Federation delivery, incoming activities, email and other background work depend on Sidekiq. Growing queue latency indicates that CPU, database connections or worker concurrency needs attention.
Instances following many remote accounts or serving more active local users.Wymagania sprzętowe Mastodona: pamięć RAM, procesor, pamięć masowa i federacja
Zaplanuj sprzęt Mastodona pod kątem pamięci RAM, CPU, PostgreSQL, Redis, Sidekiq, przechowywania multimediów i federacji, z praktycznymi zaleceniami dotyczącymi niestandardowej instalacji ZimaOS.
APP
Mastodon requirements at a glance
Mastodon upstream defines its software stack and scaling controls, but not one universal production hardware minimum. A complete instance combines Rails/Puma, the streaming API, Sidekiq, PostgreSQL, Redis and media processing, so practical host sizing must cover the whole stack plus federation and media growth.
- CPU
- No numerical official minimum published. More web workers, streaming processes and Sidekiq concurrency use more CPU and database connections.
- RAM
- No numerical official minimum published. More Puma worker processes increase RAM use, while PostgreSQL, Redis and background workers also share the host.
- Storage
- No numerical official minimum published. Local media cache, user uploads, PostgreSQL and backups can grow quickly; object storage becomes useful as the instance scales.
- Database & queues
- PostgreSQL is the main database; Redis and Sidekiq handle cache/queues, and Node.js powers streaming. These services all contribute to real host demand.
- GPU
- No dedicated GPU is required for ordinary Mastodon web, federation or media-serving workloads.
- Best Zima starting point
- ZimaBoard 2 1664 is the safer compact class for a small personal/community instance; ZimaCube 2 Pro adds stronger CPU, storage expansion and network headroom as federation and media grow.
From official requirements to the right setup
Mastodon sizing starts with active local users, federation volume and media retention, then maps those variables to Rails/Sidekiq concurrency, database load and persistent storage.
-
Official requirements
Separate upstream software requirements from hardware sizing. Mastodon currently requires a modern Ruby/PostgreSQL/Redis/Node.js/FFmpeg stack, but the official project does not publish one universal CPU, RAM or disk floor.
-
Confirm your needs
Estimate request and background-job concurrency. Web/Puma workers trade memory for throughput, while Sidekiq threads increase background throughput and database-connection demand.
-
Leave room to grow
Plan PostgreSQL, Redis and media growth together. Local filesystem storage is suitable for small servers, while object storage and database scaling become relevant as remote media cache, user uploads and federation traffic expand.
-
Run it on ZimaOS
On ZimaOS, use Install Custom App with an adapted official Mastodon Compose configuration. Persist PostgreSQL, Redis and media volumes, configure the immutable federation domain, HTTPS and SMTP, then monitor Sidekiq queues, database growth and disk usage before scaling.
Check every playback client
- Expected local active users
- Federation traffic and followed remote accounts
- Media-cache and upload retention policy
- PostgreSQL and Redis persistence
- Sidekiq and web concurrency settings
- SMTP and HTTPS/domain configuration
- Object storage or local media path
- Search, translation and other optional services
Official minimum requirements
Current Mastodon documentation defines the application stack and explains how CPU, RAM and database connections change with concurrency, but does not publish a universal production hardware table.
Do not label an arbitrary 2 GB, 4 GB or 8 GB figure as Mastodon's official minimum. For a ZimaOS deployment, 16 GB is a practical small-instance host class because PostgreSQL, Redis, Rails, Sidekiq and streaming all share the machine, but that is a workload recommendation rather than an upstream requirement.
| Requirement | Official minimum | What this supports |
|---|---|---|
| CPU minimum | No numerical official minimum published | Mastodon's scaling guide explains that more threads/processes consume CPU differently but does not set one production core-count floor. |
| RAM minimum | No numerical official minimum published | More Puma processes increase memory use; PostgreSQL, Redis, Sidekiq and streaming also need host memory. |
| Storage minimum | No numerical official minimum published | Capacity depends on PostgreSQL, uploads, remote media cache, logs and backup retention. |
| Core database | PostgreSQL 14+ | The current upstream repository lists PostgreSQL 14 or newer. |
| Queue/cache | Redis 7.0+ plus Sidekiq | Redis stores queue/cache state while Sidekiq processes background federation and other jobs. |
| Streaming | Node.js-based streaming API | Streaming processes add long-lived connections and their own database/CPU demand. |
| Media processing | FFmpeg 5.1+ plus image-processing tools | Media uploads and remote assets add CPU work and persistent storage growth. |
When to upgrade your hardware
Mastodon should scale when queue latency, database pressure or media growth shows that the current host can no longer keep up with the instance's federation workload.
Sidekiq queues stop clearing quickly
PostgreSQL or web workers push memory pressure
Media cache and backups dominate storage
More Puma worker processes consume more RAM, while PostgreSQL and Redis keep larger working sets as the instance grows.
Communities increasing user activity, search load or web concurrency.Remote media, local uploads, database backups and user archives can grow faster than the application itself and make storage retention the practical bottleneck.
Long-running federated servers and media-heavy communities.Plan hardware growth with confidence
Scale Mastodon by separating stateful services and media growth before simply adding more application workers to the same box.
Move Mastodon data to SSD-backed persistent storage
PostgreSQL and frequently accessed media benefit from predictable low-latency storage, while backups can live on larger secondary disks.
Use SATA/NVMe storage with ZimaBoard 2 or ZimaCube 2 instead of keeping the only live database/media copy on onboard eMMC.Add RAM before multiplying Puma processes
More web processes can improve throughput but each process allocates its own memory. Keep enough RAM for PostgreSQL, Redis and the OS.
Use the 16 GB ZimaBoard 2 for a compact instance or ZimaCube 2 Pro when broader consolidation and database growth justify it.Use object storage as media growth accelerates
Mastodon documents local filesystem media as suitable for small servers and object storage as the more scalable path.
ZimaCube 2 can retain large local media/backups, but external S3-compatible object storage can reduce local capacity pressure.Split database, cache or web roles when one host becomes the bottleneck
Mastodon's scaling guide covers PgBouncer, separate Redis, replicas and multiple web/streaming processes. Scale architecture before forcing one box to carry every role indefinitely.
Use multiple systems only after validating network, backup and failure-domain design.Can it run on ZimaOS?
Mastodon 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 Mastodon's official Docker/Compose assets, but federation identity and persistent state make careful setup important.
Custom install Mastodon in ZimaOS
Use Install Custom App with an adapted official Mastodon Compose file. Persist PostgreSQL, Redis and public/system media data, configure SMTP and HTTPS, and choose the federation domain carefully because LOCAL_DOMAIN cannot be changed safely later.
Custom install Mastodon in the ZimaOS app ↗Use Mastodon's official container definitions
The upstream repository includes Docker and docker-compose deployment files for Mastodon plus the documented PostgreSQL, Redis, Sidekiq and streaming stack.
Open the official Mastodon repository ↗Plan backups and media retention before opening federation
Mastodon treats PostgreSQL as the most important backup target, followed by application secrets, user uploads and Redis state. Retention settings help prevent remote-media growth from consuming storage indefinitely.
Review Mastodon backup guidance ↗Choose Zima hardware for Mastodon
Mastodon is a multi-service social server, so memory, database I/O and storage retention matter more than GPU performance. Small instances fit compact Zima hardware, while media-heavy federated communities benefit from stronger storage and CPU headroom.
Is this a small personal/community instance or a larger federated service with growing media and background jobs?
Small personal or community instance
Use 16 GB host RAM and SSD-backed PostgreSQL/media persistence so the multi-service stack has practical headroom.
- Best compact starting pointZimaBoard 2 1664
Growing federation, media or broader service stack
Prioritize stronger CPU, SSD expansion, larger bulk storage and faster networking, while considering object storage and split services as the instance scales.
- Storage-first platformZimaCube 2 Standard
- Higher-headroom platformZimaCube 2 Pro
These are workload-based recommendations, not user-count or federation-throughput guarantees. Remote follow graphs, media retention, web concurrency, Sidekiq queues, database cache, search and optional services can change requirements substantially.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 1664 | Small personal or community Mastodon instances. | Rails/Puma, streaming, Sidekiq, PostgreSQL, Redis, media cache and backups on one modest host. |
|
Add SSD storage for PostgreSQL and media. Four CPU cores and 16 GB RAM are practical small-instance resources, not a guarantee for a public community with heavy federation. | Get Now |
| ZimaCube 2 Standard | Mastodon with larger local media, backups and a broader home-server stack. | Small-to-medium federation activity plus multi-drive media retention and other self-hosted services. |
|
The 8 GB memory configuration can be less attractive than a 16 GB ZimaBoard for memory-heavy Mastodon. Choose Standard mainly for storage topology, not because it offers more RAM. | Get Now |
| ZimaCube 2 Pro | A growing Mastodon host needing stronger CPU, 16 GB RAM and expandable SSD/HDD storage. | Higher federation/background-job activity, larger PostgreSQL working set, media retention and several co-hosted services. |
|
Large public instances may still need separate database/cache/web roles or object storage; one stronger box is not equivalent to a horizontally scaled Mastodon architecture. | 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 Mastodon RAM, CPU, storage, PostgreSQL, Redis, media growth and ZimaOS custom installation without inventing an upstream hardware minimum.
How much RAM does Mastodon need?
Mastodon does not publish one universal production RAM minimum. The real host must cover Rails/Puma, streaming, Sidekiq, PostgreSQL and Redis. For a small ZimaOS instance, 16 GB is a practical host class, but it is not an official Mastodon minimum.
Can Mastodon run on 4 GB or 8 GB RAM?
Small instances can be tuned to modest memory budgets, but upstream does not define 4 GB or 8 GB as official production tiers. More Puma processes increase RAM use, and database/cache services share the same host unless separated.
How many CPU cores does Mastodon need?
There is no universal official core-count minimum. Web threads, Puma workers, streaming processes and Sidekiq concurrency all use CPU differently, so the correct core count depends on request volume and federation/background work.
How much storage does Mastodon need?
Mastodon does not publish one universal disk minimum. Plan capacity for PostgreSQL, local user uploads, remote media cache, logs and backups. Retention policies and object storage can dramatically change local disk growth.
Does Mastodon need PostgreSQL and Redis?
Yes. PostgreSQL is the primary database, while Redis is used for caching and Sidekiq queues. The current upstream project lists PostgreSQL 14+ and Redis 7.0+.
Does Mastodon need a GPU?
No dedicated GPU is required for ordinary Mastodon web, streaming, federation and background-processing workloads. CPU, RAM, database I/O and media storage are the relevant hardware dimensions.
Can ZimaBoard 2 run Mastodon?
Yes for a small instance with careful persistence and monitoring. The 16 GB ZimaBoard 2 is the stronger compact choice because Mastodon is a multi-service stack; add SSD storage for PostgreSQL and media instead of relying only on eMMC.
When should Mastodon use object storage?
Local filesystem media is suitable for small servers, but Mastodon documents external object storage as the more scalable path. It becomes useful when remote-media cache, local uploads and backup capacity start dominating the host.
What sources informed this Mastodon hardware guide?
The guide uses Mastodon's current repository and administrator documentation for software dependencies, concurrency behavior, storage scaling and backups. Current Zima product pages are used only for hardware specifications and workload matching.
