A larger monitor set or 20–60-second intervals create more network requests, database writes and scheduler work. Complex monitor types can add more overhead than simple Ping checks.
For users moving from a handful of home services to dozens or hundreds of checks.Requisitos de hardware do Uptime Kuma: RAM, CPU, armazenamento e monitores
Conheça os requisitos de hardware do Uptime Kuma: RAM, CPU, armazenamento, monitores, SQLite, intervalos de verificação e hardware compatível com o ZimaOS.
Uptime Kuma hardware requirements at a glance
Uptime Kuma is designed to be lightweight, but current upstream does not publish one universal CPU, RAM or disk minimum. Resource use grows with monitor count, check interval, monitor type, retained heartbeat history, notifications and version-specific behavior.
- CPU
- No universal upstream CPU-core minimum is published. Most HTTP/Ping/DNS checks are light, while short intervals, many monitors and more complex monitor types increase recurring work.
- RAM
- No universal upstream RAM minimum is published. Tencent Cloud reports roughly 50–200 MB typical use for light deployments, while Geliştir Cloud publishes a 512-MB minimum. These third-party figures are not guarantees: a supplied upstream issue reports OOM even with 2 GB on v2.0.0-beta.3 at around 50 monitors.
- Storage
- Persist /app/data on local storage. Current upstream explicitly warns that NFS is not supported for this data path. Monitor history, status pages and database growth determine capacity over time.
- Runtime
- Docker is the easiest upstream deployment path. For non-Docker installs, current upstream requires Node.js 20.4 or newer, Git and PM2.
- Scale variable
- Monitor count alone is not enough. A few 20-second checks, many HTTP keyword/JSON checks, Docker/database monitors, short retention windows and notifications can have different resource profiles.
- Best Zima starting point
- ZimaBoard 2 832 is the default starting point for a home Uptime Kuma instance and leaves substantial margin above lightweight third-party tiers. Choose 1664 when the monitoring database, monitor count or broader observability stack grows; ZimaCube 2 is mainly for larger all-in-one monitoring/storage systems.
From official requirements to the right setup
Uptime Kuma sizing starts with monitor count and interval, then checks monitor type, retained history, database/storage placement, notifications and the other monitoring services sharing ZimaOS.
-
Official requirements
Do not treat 512 MB or 2 GB as a guaranteed universal threshold. Upstream does not publish one, and real memory behavior can differ substantially by version and monitor workload.
-
Confirm your needs
Inventory monitor types and intervals. HTTP(S), Ping, DNS, TCP, Docker, database and JSON/keyword checks can create different CPU/network/database work, especially at 20–60-second intervals.
-
Leave room to grow
Persist /app/data on local disk/volume. Current upstream warns that NFS filesystems are not supported, so keep the active Kuma data path off NFS/SMB-style network storage.
-
Run it on ZimaOS
Run the real monitor set while watching RSS/heap, CPU, data-directory growth and check latency. Increase hardware only after confirming the bottleneck instead of copying a provider's generic minimum.
Check every playback client
- Number of monitors now and projected growth
- Heartbeat/check interval for each monitor
- HTTP/Ping/DNS/TCP versus Docker/database/JSON monitor types
- Notification integrations and retry behavior
- Persistent /app/data on local disk or Docker volume
- Heartbeat/history retention and status-page usage
- Current Uptime Kuma major version
- Other ZimaOS observability/networking services sharing the host
Official minimum requirements
Current upstream Uptime Kuma provides software/runtime requirements and a supported storage model, but it does not publish a fixed CPU/RAM/disk hardware table.
The safe current statement is 'no universal upstream hardware minimum published.' Geliştir's 1-vCPU/512-MB/5-GB tier and Tencent's 50–200-MB typical RAM are useful light-deployment references only. Issue #5884 shows why they must not be turned into guarantees.
| Requirement | Official minimum | What this supports |
|---|---|---|
| CPU minimum | No universal upstream minimum published | Current README focuses on installation and runtime dependencies rather than a core-count floor. |
| RAM minimum | No universal upstream minimum published | Third-party tiers vary and a v2 beta user reported OOM at 2 GB with about 50 monitors. |
| Non-Docker Node.js | Node.js 20.4+ | Current upstream non-Docker requirement. |
| Persistent data | /app/data on local storage/volume | Current upstream Docker instructions persist /app/data. |
| Network filesystem | NFS not supported for /app/data | Current upstream README explicitly warns against NFS for the active data path. |
| Third-party small tier | 1 vCPU, 512 MB RAM, 5 GB disk | Geliştir Cloud provider minimum for its version-1.23.11 offering; not upstream requirement. Its recommended tier is 2 vCPU, 2 GB RAM and 20 GB disk. |
When to upgrade your hardware
Uptime Kuma should be upgraded from measured monitor workload and memory/database pressure, not a single fixed monitor count.
Monitor count and short intervals increase recurring checks
Memory growth or GC/OOM appears on the current version
Monitoring history and status data make storage more important
The supplied upstream issue shows v2.0.0-beta.3 crashing from OOM on a 2-GB host at roughly 50 monitors. Because the issue had no official sizing answer and was closed stale, treat unusual memory growth as something to diagnose by version/configuration rather than a universal 2-GB requirement.
For deployments showing rising RSS, frequent GC, restarts or OOM kills.Persistent monitor state and history live under /app/data. More monitors and longer operation increase database/storage writes and backup needs even when CPU remains low.
For long-running instances with many monitors and retained status history.Plan hardware growth with confidence
Uptime Kuma scales most cleanly by keeping its data local, controlling monitor intervals and treating wider observability services separately.
Put /app/data on local SSD-backed storage
Current upstream explicitly rejects NFS for the active data path. Local SSD/volume storage is the safer persistence path for the Kuma database and configuration.
Use SATA/NVMe SSD for important monitoring data.Increase check intervals before buying more CPU
Short intervals multiply recurring monitor work. Many home services do not need 20-second checks, so interval tuning can reduce load and noise.
Tune monitor cadence based on the service's real availability needs.Separate metrics/logs from uptime checks
Uptime Kuma answers availability/health questions; Grafana/Prometheus/Loki-class observability workloads can consume far more resources and should be sized independently.
Add RAM/storage for the broader monitoring stack rather than calling it Uptime Kuma overhead.Upgrade RAM when measured Kuma or co-hosted services need it
Move to 16 GB only after confirming memory pressure from Kuma's actual monitor workload or the rest of the ZimaOS stack.
Choose ZimaBoard 2 1664 or ZimaCube 2 Pro based on system-wide measurements.Can it run on ZimaOS?
Uptime Kuma is currently available in the ZimaOS App Store under Networking. It is a natural fit for an always-on home server because it can monitor both local services and remote endpoints.
Install Uptime Kuma from the ZimaOS App Store
ZimaOS currently lists Uptime Kuma in the Networking category as a self-hosted monitoring tool.
Open Uptime Kuma in the ZimaOS App StoreKeep Kuma data on local persistent storage
Upstream requires persistence under /app/data and explicitly warns that NFS is unsupported. Keep the active database/configuration local to the ZimaOS host.
Read Uptime Kuma installation guidanceTreat monitor scale as a measured workload
Do not assume a provider's 512-MB minimum applies to every Uptime Kuma workload. Test the actual number/types of monitors and intervals after installation.
Review the upstream system-requirements issueChoose Zima hardware for your Uptime Kuma workload
A normal home Uptime Kuma instance fits comfortably on ZimaBoard 2 832. Larger hardware should be selected for unusually large monitor sets, broader observability stacks, storage or many co-hosted services.
Is Uptime Kuma monitoring a normal home/self-hosted stack, or becoming part of a much larger observability platform?
Home monitoring and a modest number of services
Start with ZimaBoard 2 832. Its N150 and 8 GB RAM leave large practical headroom above common third-party lightweight deployment tiers. Choose 1664 when the wider monitoring/application stack creates measured memory pressure.
- Home Uptime Kuma monitoringZimaBoard 2 832
- More monitors and larger co-hosted observability stackZimaBoard 2 1664
Large monitoring/storage/all-in-one home-lab platform
Choose ZimaCube 2 when storage, databases, metrics/logging or many services justify it. Creator Pack has no Uptime Kuma-specific GPU benefit.
- Storage-first monitoring/NASZimaCube 2 Standard
- Heavier all-in-one observability/home-lab stackZimaCube 2 Pro
- Only when unrelated GPU/AI workloads require itZimaCube 2 Creator Pack
This is a workload guide, not a guaranteed monitors-per-GB formula. Uptime Kuma version, monitor type, check interval, retention, notification workload and database behavior can materially change resource use.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | The default current Zima option for Uptime Kuma home monitoring. | Uptime Kuma, status pages, notifications and several lightweight network/monitoring apps. |
|
Keep /app/data on local persistent storage; very large monitor sets or version-specific memory issues should be measured rather than estimated. | Get Now |
| ZimaBoard 2 1664 | Uptime Kuma with more monitors and a larger co-hosted observability stack. | Uptime Kuma plus Grafana, databases, reverse proxy, automation and more services. |
|
Do not claim Uptime Kuma requires 16 GB. | Get Now |
| ZimaCube 2 Standard | Storage-first monitoring/NAS where Uptime Kuma is one lightweight service. | Uptime Kuma plus storage, backups and moderate observability services. |
|
Choose for NAS capacity, not because uptime checks need an i3-class CPU. | Get Now |
| ZimaCube 2 Pro | Heavier all-in-one observability/home-lab server. | Uptime Kuma, Grafana/metrics/logging, databases, many containers and storage. |
|
Separate metrics/logs/database sizing before attributing their resource use to Uptime Kuma. | Get Now |
| ZimaCube 2 Creator Pack | Uptime Kuma on a server independently required for local AI/GPU workloads. | Uptime Kuma plus unrelated local AI or creator services. |
|
Extreme overkill for uptime monitoring. | 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
The supplied Uptime Kuma sources disagree sharply on RAM because they describe different versions and deployment contexts. Current upstream does not publish a universal hardware minimum.
How much RAM does Uptime Kuma need?
Current upstream does not publish one universal RAM minimum. Tencent Cloud reports roughly 50–200 MB typical use for light deployments, while Geliştir Cloud lists 512 MB minimum and 2 GB recommended for its hosted template. Treat both as third-party reference points.
Is 512 MB RAM enough for Uptime Kuma?
It can be enough for some small deployments, but it is not an upstream guarantee. Geliştir Cloud lists 512 MB as its minimum; monitor count, interval, version and monitor type can raise real usage.
Why did a 2-GB Uptime Kuma container still run out of memory?
The supplied GitHub #5884 reports v2.0.0-beta.3 on RHEL9 with around 50 monitors crashing during GC despite a 2-GB container limit. The issue was closed stale without an official minimum, so it is evidence of a version/workload-specific problem rather than proof that everyone needs more than 2 GB.
What does current upstream actually require?
For Docker, upstream provides the Uptime Kuma image and persistent /app/data volume. For non-Docker installation, current README requires Node.js 20.4+, Git and PM2. It does not give a CPU/RAM hardware table.
Can Uptime Kuma data live on NFS?
No for the active /app/data path according to the current upstream README. Use a local directory or Docker volume instead.
What does Railway add to sizing?
Railway's template is most useful for persistence architecture: it describes Uptime Kuma configuration/history in persistent /app/data and emphasizes preserving the monitoring database. It does not provide a universal CPU/RAM minimum.
What does the Medium Kubernetes example prove?
The supplied Medium article shows a Helm-style Kubernetes deployment with a 4-Gi persistent-volume example and intentionally leaves CPU/memory resources unspecified. That is deployment configuration, not hardware sizing evidence.
Can ZimaBoard 2 832 run Uptime Kuma?
Yes for a normal home monitoring workload. Four N150 cores and 8 GB RAM provide substantial headroom over common lightweight provider tiers. Keep /app/data on local persistent storage and monitor real usage as checks grow.
What sources and further reading informed this Uptime Kuma hardware guide?
The upstream Uptime Kuma repository is the primary authority: it supports 20-second intervals, many monitor types, Docker deployment, requires Node.js 20.4+ for non-Docker installs and explicitly says NFS is not supported for /app/data, but it does not publish CPU/RAM minimums. GitHub issue #5884 is a user report of 2-GB OOM on v2.0.0-beta.3 with roughly 50 monitors and was closed stale without an official sizing answer. Tencent Cloud says Uptime Kuma typically uses about 50–200 MB RAM, which is third-party lightweight-use guidance. Railway contributes persistence/deployment context rather than a hardware minimum. The supplied Medium Kubernetes example uses a 4-Gi volume and leaves resource limits empty. Geliştir Cloud publishes 1 vCPU/512 MB/5 GB minimum and 2 vCPU/2 GB/20 GB recommended for its version-1.23.11 marketplace deployment; those provider tiers are not upstream guarantees.
