High public request rates, many TLS handshakes or compression can make CPU more relevant.
Public sites and reverse proxies serving significant traffic.Caddy Hardware Requirements: RAM, CPU, TLS & Reverse Proxy
Plan Caddy hardware for RAM, CPU, TLS certificates, reverse proxy traffic and logs, with practical ZimaOS custom-install networking guidance.
Caddy requirements at a glance
Caddy is a lightweight Go web server and reverse proxy with automatic HTTPS. Upstream documents installation and Docker deployment but does not publish a numerical hardware sizing table.
- RAM
- No numerical official minimum published. Basic reverse proxy use is light; configuration size, modules and request concurrency affect memory.
- CPU
- No numerical official core minimum published. TLS handshakes, compression, high request rates and plugins increase CPU demand.
- Storage
- No universal official minimum. Persistent /data stores certificates and PKI state; logs/static content can dominate disk usage.
- Ports
- Standard Docker examples publish 80/tcp, 443/tcp and 443/udp for HTTP/HTTPS/HTTP3.
- GPU
- No GPU is required for web serving, TLS or reverse proxying.
- Best Zima starting point
- ZimaBoard 2 832 is far more than enough for normal home reverse-proxy use; networking/port conflicts matter more than raw compute.
From official requirements to the right setup
Size Caddy from traffic and TLS/logging features, but first make sure its host ports do not conflict with ZimaOS or another reverse proxy.
-
Official requirements
Start with the official Caddy Docker image or binary. Upstream publishes no numerical CPU/RAM minimum for normal serving.
-
Confirm your needs
Decide whether Caddy will terminate public HTTPS, serve static files, compress responses or only reverse proxy internal services. These choices drive CPU, storage and logging load.
-
Leave room to grow
Persist /data and /config because certificate state and autosaved configuration must survive container recreation.
-
Run it on ZimaOS
On ZimaOS, use Install Custom App only after checking host ports. Standard Caddy ports 80/443 may conflict with ZimaOS dashboard/proxy services, so remap or redesign the networking before deployment.
Check every playback client
- HTTP/HTTPS host ports
- Existing ZimaOS/reverse-proxy port use
- Number of proxied services
- Public request volume
- TLS certificate persistence
- Log retention
- Static file volume
- Custom Caddy modules
Official minimum requirements
Caddy's official docs explain supported deployment methods and persistent directories but do not define numerical server hardware minimums.
Do not invent a RAM/core minimum for Caddy. For a home server, the more important planning questions are port ownership, TLS persistence, traffic volume and whether custom modules add extra work.
| Requirement | Official minimum | What this supports |
|---|---|---|
| RAM minimum | No numerical official minimum published | Depends on traffic, config, modules and caching/logging choices. |
| CPU minimum | No numerical official minimum published | TLS, compression and high concurrency can increase CPU use. |
| Storage minimum | No numerical official minimum published | Certificates, logs, config and static content determine usage. |
| Docker ports | 80/tcp, 443/tcp and 443/udp | Current official Compose example for HTTP, HTTPS and HTTP/3. |
| Persistent data | /data and /config | Official Compose example persists certificate/PKI and configuration state. |
| Custom plugins | Custom image/build required | Official docs recommend xcaddy/custom builds for third-party modules. |
When to upgrade your hardware
Caddy should scale only when traffic or enabled features make the proxy itself a measurable bottleneck.
TLS and request throughput saturate CPU
Logs or static content dominate disk
Caddy proxies many local services
Verbose access logs and locally served assets can consume much more disk than Caddy's certificate state.
Long-retention logging and static-hosting workloads.The proxy may remain light while the upstream apps become the real CPU/RAM bottleneck.
Large homelabs and consolidated ZimaOS servers.Plan hardware growth with confidence
Scale Caddy based on network and upstream workload rather than treating it like a database or media server.
Keep certificate/config state on durable storage
Persist /data and /config so TLS state survives upgrades and container recreation.
Any ZimaBoard/ZimaCube storage is sufficient for normal certificate state.Increase CPU only for heavy TLS/proxy traffic
Basic homelab proxying is lightweight; stronger CPU matters mainly at higher request rates or with CPU-heavy modules.
ZimaBoard 2 832 handles normal home reverse proxying; ZimaCube 2 Pro is only needed when the broader workload warrants it.Use faster networking for high-throughput upstreams
Large local transfers or many proxied services can make network bandwidth more important than memory.
ZimaBoard 2 has dual 2.5GbE; ZimaCube 2 Pro adds 10GbE connectivity.Separate proxy and upstream apps when failure isolation matters
A dedicated proxy can simplify port ownership and reduce the blast radius of app failures.
Use a separate node only when the architecture, not raw Caddy compute, justifies it.Can it run on ZimaOS?
Caddy is not currently confirmed as a public official one-click ZimaOS App Store page in the sources checked for this guide. It can run through Install Custom App, but port conflicts require careful planning.
Custom install Caddy in ZimaOS
Use Install Custom App with the official Caddy image, persist /data and /config, and verify that host ports 80/443 are not already owned by ZimaOS or another reverse proxy before mapping them.
Custom install Caddy in the ZimaOS app ↗Use Caddy's official Docker Compose pattern
The official docs publish 80/tcp, 443/tcp and 443/udp plus persistent /data and /config volumes.
Review Caddy Docker setup ↗Plan ZimaOS HTTPS and reverse proxy behavior together
ZimaOS documentation also discusses putting apps behind reverse proxies such as Caddy, so local certificate trust and host-port ownership should be designed as one system.
Review ZimaOS HTTPS proxy guidance ↗Choose Zima hardware for Caddy
Caddy itself is light; choose Zima hardware for the apps and network traffic behind the proxy.
Is Caddy serving a normal homelab or a higher-throughput multi-service environment?
Normal home reverse proxy
Use ZimaBoard 2; port and certificate configuration are more important than compute.
- Best starting pointZimaBoard 2 832
High-throughput local services or broader server stack
Choose the larger platform for networking and upstream app needs rather than Caddy alone.
- More app headroomZimaBoard 2 1664
- 10GbE-capable platformZimaCube 2 Pro
These are practical reverse-proxy recommendations, not request-per-second guarantees. TLS settings, modules, logging, compression, upstream latency and network topology can change performance.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Normal homelab Caddy reverse proxying. | Automatic HTTPS, a handful of proxied apps and light static content. |
|
The main deployment risk is port conflict with ZimaOS/another proxy, not lack of CPU or RAM. | Get Now |
| ZimaBoard 2 1664 | Caddy plus a larger all-in-one app stack. | Reverse proxying alongside many databases, dashboards and other containers. |
|
Extra RAM is for the rest of the stack; Caddy itself usually remains lightweight. | Get Now |
| ZimaCube 2 Pro | High-throughput local services where 10GbE and stronger upstream hardware matter. | Caddy plus many high-bandwidth services and larger self-hosted workloads. |
|
Choose Pro for the wider system/network workload, not because Caddy requires a Core i5. | 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 Caddy RAM, CPU, TLS, ports, Docker and ZimaOS deployment.
How much RAM does Caddy need?
Caddy does not publish a numerical official server RAM minimum. Basic reverse-proxy use is lightweight; traffic, modules and logging determine practical memory.
How many CPU cores does Caddy need?
There is no numerical official core minimum. TLS handshakes, compression and high concurrency increase CPU demand.
How much storage does Caddy need?
There is no universal minimum. Persist /data for certificate/PKI state and /config for autosaved configuration, while logs and static files can require additional space.
Which ports does Caddy use in Docker?
The official Compose example exposes 80/tcp, 443/tcp and 443/udp for HTTP, HTTPS and HTTP/3.
Does Caddy need a GPU?
No dedicated GPU is required for TLS, static serving or reverse proxying.
Can ZimaBoard 2 run Caddy?
Yes. ZimaBoard 2 is far more than enough for normal home reverse-proxy use.
Why can Caddy conflict with ZimaOS?
Reverse proxies often want host ports 80 and 443, which may already be used by ZimaOS or another proxy. Check host-port ownership before deploying the standard Caddy mapping.
Should I upgrade hardware for Caddy or for the proxied apps?
Usually the proxied applications, storage and network traffic determine the server size. Upgrade Caddy-specific compute only when monitoring shows the proxy itself is saturated.
What sources informed this Caddy hardware guide?
The guide uses Caddy's current official installation/running documentation plus ZimaOS HTTPS guidance and current Zima product pages.
