Measure open connections, network saturation and fan-out during a publish burst; distinguish server saturation from mobile push delivery behavior.
Many connected clients or busy shared topics.ntfy-hardwarevereisten: RAM, CPU, opslag, berichtcache en verbindingen
Plan ntfy RAM-, CPU-, meldingsverbindingen, berichtcaching en bewaartijd voor bijlagen, met Docker-poorttoewijzing en praktische serverrichtlijnen voor ZimaOS.
APP
ntfy hardware requirements at a glance
ntfy has no numerical whole-host hardware minimum in the reviewed installation documentation. Size persistent subscribers, message rate, retained cache and attachments. The Kubernetes example limits are container examples rather than a server minimum.
- RAM
- No numerical official minimum published. Persistent subscriber connections, in-memory state and cache behavior determine practical usage; sample Kubernetes limits are not whole-host requirements.
- CPU
- No numerical official minimum published. Message rate, fan-out, TLS and attachment transfers matter more than a quiet notification dashboard.
- Storage
- Persist message cache, authentication data and configured attachments. Estimate retained volume from message rate, payload size and retention; enforce attachment limits.
- Database / runtime
- SQLite is the default storage path without an external database dependency; current configuration also supports PostgreSQL for supported stores.
- Network / delivery
- The official container listens on port 80. Map it to an available host port; configure the proxy and base URL. iOS delivery may need the documented upstream push arrangement.
- Best Zima starting point
- ZimaBoard 2 832 is a practical private notification host. Higher tiers should be justified by measured connection/fan-out demand or other co-hosted services.
From official requirements to the right setup
Plan the complete ntfy workload before selecting a server.
-
Official requirements
Use the official binwiederhier/ntfy image and the selected stable release. Separate the Docker deployment facts from resource limits appearing in example Kubernetes manifests.
-
Confirm your needs
Estimate simultaneously connected subscribers, peak publish rate, subscribers per topic and attachment traffic. Fan-out can turn one incoming notification into many outgoing deliveries.
-
Leave room to grow
Configure persistent cache/auth paths and attachment storage with explicit retention and limits. Estimate cache capacity as retained messages ร average stored size, then add metadata and backup headroom.
-
Run it on ZimaOS
Custom install in ZimaOS with the serve command, persistent configuration and writable data paths. Map container port 80 to an unused host port and configure base URL, reverse proxy and intended topic access.
Check every playback client
- Simultaneously connected subscribers
- Peak messages per second
- Subscribers per busy topic
- Message cache duration
- Average payload and attachment size
- Attachment limits and expiration
- Available host port / reverse proxy
- Persistent auth/cache and recovery
Official minimum requirements
Checked on October 23, 2026 against official documentation and the project repository. Latest stable release observed: v2.33.1. Numerical requirements below retain their original scope.
The 128 MiB / 500m CPU values in sample Kubernetes manifests are deployment example limits, not an official whole-server minimum. Notification storage follows retention policy, while connection count and fan-out determine network and memory pressure.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Host RAM | No numerical official minimum published. | Kubernetes example memory limits describe sample containers, not a host baseline. |
| CPU cores | No numerical official minimum published. | Publish rate, fan-out, TLS and attachment activity determine compute load. |
| Disk capacity | No numerical official minimum published. | Cache and attachment retention must be configured for the workload. |
| Official image | binwiederhier/ntfy with serve command | The image supports amd64, armv6, armv7 and arm64 in the official installation guide. |
| Storage backend | SQLite by default; PostgreSQL is also documented | Persist selected cache/auth stores and include any external database in the resource budget. |
| Container network | HTTP port 80 | Use an unused host mapping to avoid taking the ZimaOS or reverse-proxy web port. |
| Persistent paths | /etc/ntfy and configured cache/auth/attachment paths | The container does not supply a ready-made server.yml; create and mount your configuration when using a file. |
When to upgrade your hardware
Use observed ntfy workload pressure to decide when an upgrade is warranted.
Subscribers disconnect or deliveries lag under load
Persistent cache or database writes fall behind
Attachments consume capacity or bandwidth
Check database latency, memory pressure and storage health before increasing connection limits or introducing more workers.
Higher message rates and long cache retention.Apply total/per-file limits and expiration and measure egress, rather than adding CPU to a bandwidth or retention problem.
Image/file notifications and long attachment retention.Plan hardware growth with confidence
Address storage, memory, compute and deployment limits separately.
Use durable cache and auth storage
Place state on reliable writable storage and preserve configuration and credentials.
ZimaBoard 2 with SATA/PCIe SSD if stateful I/O warrants it.Add memory for measured connections
Choose additional host RAM when subscriber count and companion apps actually create memory pressure.
ZimaBoard 2 1664 for shared-host headroom.Bound retention before expanding capacity
Set cache duration and attachment limits; add disk only for a deliberate retention requirement.
SSD storage or ZimaCube 2 when other archive workloads justify its bays.Scale the actual bottleneck
Upgrade CPU/network for measured delivery pressure, or isolate the notification host from heavy background jobs.
Stronger server hardware only after message/fan-out measurement.Can it run on ZimaOS?
No specific public official one-click ZimaOS app page was verified. Use Custom Install with the upstream container rather than treating an unverified community entry as official one-click support.
Custom install ntfy in ZimaOS
Run binwiederhier/ntfy with serve, mount configuration and writable state, and map container port 80 to a free host port. Set intended access controls and reverse-proxy/base-url configuration.
Custom install ntfy in the ZimaOS app โUse the official ntfy deployment instructions
Keep the selected stable release, persistent paths and companion services aligned with upstream documentation.
Review ntfy official installation โPlan cache, access and push delivery
Review cache/auth backends, attachment retention, proxy handling and the self-hosted iOS push arrangement.
Review ntfy deployment details โWhich Zima hardware fits ntfy?
Start with the lowest reasonable host for the actual workload. Product specifications were checked against the current product pages.
Which workload best matches your ntfy deployment?
Private home-server notifications
Use a modest host with persistent state and bounded retention.
- Workload optionZimaBoard 2 832
Notifications plus a broader app stack
Choose more RAM for measured contention and shared services.
- Workload optionZimaBoard 2 1664
These are practical workload recommendations, not official app requirements, compatibility certification, measured capacity limits or performance guarantees. Include all co-hosted services and independent backups.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Private notification server | Home automation alerts, backups and modest subscriber traffic. |
|
No official user/connection capacity is claimed; set cache and attachment limits. | Get Now |
| ZimaBoard 2 1664 | Notification host with more services | More shared memory headroom and persistent state on suitable storage. |
|
16 GB is not a ntfy minimum and does not increase the N150 CPU or guarantee mobile push latency. | 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
Answers to ntfy RAM, CPU, storage, Docker, database and ZimaOS sizing questions.
How much RAM does ntfy need?
No numerical official minimum published. Measure connected subscribers and burst traffic with your cache/backend configuration. Example Kubernetes limits are not whole-host minimums.
How many CPU cores are required for ntfy?
No numerical core floor is published in the reviewed installation guide. Message frequency, fan-out, TLS and attachment traffic determine the actual workload.
Does ntfy require PostgreSQL?
No. SQLite is the default backend and requires no separate database service. Current configuration also supports PostgreSQL; use its documented settings and size the external database separately if selected.
How much cache and attachment storage do I need?
Estimate message rate ร average stored size ร retention period, then add metadata, attachments and headroom. Configure attachment expiration and size limits, and confirm the resulting peak on-disk usage.
Does ntfy need a GPU or special CPU architecture?
No dedicated GPU is required. The official image supports amd64 as well as several ARM architectures; use amd64 on Zima hardware.
Can ZimaBoard 2 host ntfy?
It is a practical private notification host with appropriate persistent storage and network configuration. Test real message bursts and active subscribers rather than relying on idle usage.
Why do iOS notifications arrive late on a self-hosted server?
Server CPU is only one part of delivery. The ntfy documentation describes an upstream push mechanism for self-hosted iOS use; check that configuration and client behavior before assuming a hardware upgrade will fix latency.
When should I choose ZimaCube 2?
ntfy alone rarely warrants multi-bay hardware. Consider a larger system for measured delivery load or for the other apps and retained data you intend to consolidate, after applying sensible retention limits.
What sources informed this ntfy hardware guide?
Official project requirements, installation/configuration documentation, repository/release information and the current Zima product pages were checked on October 23, 2026. Practical hardware recommendations are editorial sizing guidance rather than upstream minimums.
