PostHog says open-source deployments should scale to roughly 100K events per month and recommends Cloud beyond that.
Projects growing from hobby analytics toward production product analytics.PostHogのハードウェア要件：RAM、イベント、ストレージ、セルフホスティング
RAM、イベント数、ストレージ、Dockerを考慮したPostHog Hobbyのセルフホスティングを計画。公式推奨の4 GBメモリと、実用的なZimaOSカスタムインストールの容量目安を紹介。
PostHog requirements at a glance
PostHog now frames self-hosting as an advanced hobby deployment rather than its primary production path. The official repository recommends 4 GB memory and roughly 100,000 events per month.
- RAM
- Official recommendation for the open-source hobby deploy: 4 GB memory.
- Event volume
- PostHog says open-source deployments should scale to approximately 100,000 events per month; beyond that it recommends PostHog Cloud.
- CPU
- No universal hobby-deploy core minimum is published. Event ingestion, queries and session replay processing drive CPU demand.
- Storage
- No universal numerical minimum is published. Analytics events, session replay data, Docker state and backups can grow quickly.
- GPU
- No GPU is required for normal product analytics, feature flags or web analytics self-hosting.
- Best Zima starting point
- ZimaBoard 2 832 exceeds the 4 GB recommendation for hobby use; 16 GB gives more room, but bigger hardware does not change PostHog's ~100K-events/month open-source guidance.
From official requirements to the right setup
Treat PostHog self-hosting as a bounded hobby workload. Size from event volume and enabled products, then keep the official ~100K events/month boundary visible.
-
Official requirements
Start with the official recommendation of 4 GB memory for the open-source hobby deploy on Linux with Docker.
-
Confirm your needs
Estimate monthly events and optional product load such as session replay. PostHog explicitly says open-source deployments should scale to about 100K events per month.
-
Leave room to grow
Plan storage for analytics state, replay/event data, Docker layers and backups. This is a multi-service analytics stack rather than one small web container.
-
Run it on ZimaOS
On ZimaOS, use Install Custom App only as an advanced hobby deployment. Persist all service data, keep backups, and migrate to PostHog Cloud or dedicated infrastructure when the upstream boundary is exceeded.
Check every playback client
- Monthly event volume
- Session replay usage
- Retention requirements
- Persistent analytics storage
- Docker memory budget
- Backup/restore plan
- Public HTTPS/domain
- Other ZimaOS services
Official minimum requirements
The current PostHog repository publishes a hobby-deploy memory recommendation and an explicit event-volume boundary instead of a broad production sizing table.
Use 4 GB as the official recommended memory for the hobby deployment, and treat roughly 100K events/month as the project's stated open-source scale boundary.
| Requirement | Official minimum | What this supports |
|---|---|---|
| RAM | 4 GB recommended | Current official README recommendation for the open-source hobby deploy. |
| Event-volume guidance | Approximately 100K events/month | PostHog recommends migrating to PostHog Cloud beyond this open-source scale. |
| CPU minimum | No universal numerical minimum published | CPU demand depends on ingestion, queries and enabled analytics products. |
| Storage minimum | No universal numerical minimum published | Events, replays, analytics databases, Docker data and backups determine capacity. |
| Deployment class | Advanced open-source hobby deployment | PostHog Cloud is the recommended general deployment path and open-source self-hosting has no support guarantees. |
When to upgrade your hardware
PostHog's most important boundary is not just hardware pressure; it is the vendor's stated hobby-deployment scope.
Monthly events approach 100K
Session replay and retained data drive disk growth
The multi-service stack competes with other ZimaOS apps
Replay and analytics data can consume storage much faster than lightweight event-only tracking.
Teams enabling session replay or keeping longer history.Even with 8–16 GB RAM, a hobby analytics stack can contend with databases, media and AI services on the same host.
All-in-one home servers.Plan hardware growth with confidence
Scale PostHog hobby deployments cautiously and keep the upstream Cloud recommendation visible.
Move persistent analytics data to SSD
Fast storage helps analytics databases and query workloads while reducing contention with the boot device.
Use SATA/NVMe storage with ZimaBoard 2 or ZimaCube 2.Use 8–16 GB RAM for practical hobby headroom
The official recommendation is 4 GB, so 8 or 16 GB gives room for Docker, the OS and co-hosted services.
ZimaBoard 2 832 or 1664.Separate PostHog from unrelated heavy workloads
If media, AI or other databases cause contention, isolation is more useful than assuming PostHog itself needs a huge home server.
Use a dedicated node if mixed workloads create sustained pressure.Migrate when event volume exceeds the hobby boundary
PostHog recommends Cloud beyond roughly 100K events/month; larger local hardware does not remove that upstream guidance.
Treat Cloud or dedicated production infrastructure as the next step rather than only a bigger Zima box.Can it run on ZimaOS?
PostHog is not currently presented as a verified public one-click ZimaOS App Store page in the catalog checked for this guide. It can be attempted through Install Custom App, but upstream explicitly frames self-hosting as an advanced hobby deployment.
Custom install PostHog in ZimaOS
Use Install Custom App only with a carefully reviewed adaptation of PostHog's official hobby deployment. Persist every stateful service, allocate at least the official 4 GB recommendation, and keep reliable backups.
Custom install PostHog in the ZimaOS app ↗Follow the official hobby-deploy boundary
PostHog's current repository recommends 4 GB memory and approximately 100K events/month as the expected open-source scale before moving to PostHog Cloud.
Review PostHog self-hosting guidance ↗Treat this as an advanced deployment
PostHog does not provide customer support or guarantees for open-source deployments, so monitor upgrades, backups and data migrations closely.
Read the PostHog repository guidance ↗Choose Zima hardware for PostHog
Zima hardware can comfortably exceed PostHog's 4 GB hobby-deploy memory recommendation, but the important limit is still the project's ~100K-events/month open-source guidance.
Is this a small hobby analytics deployment or a heavier multi-service lab?
Small hobby deployment under the stated open-source scale
8 GB leaves practical headroom over the 4 GB recommendation; use SSD-backed persistent storage.
- Best starting pointZimaBoard 2 832
- More memory headroomZimaBoard 2 1664
Heavier replay/data retention or broader lab stack
Use stronger storage/CPU only for the local lab workload, while keeping PostHog's Cloud migration boundary in mind.
- Higher-headroom lab hostZimaCube 2 Pro
These are hobby-deployment recommendations, not guarantees for event throughput, replay volume or production reliability.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Small PostHog hobby deployments. | Product/web analytics below the stated open-source scale, light replay and a few companion services. |
|
Add SSD-backed persistent storage; 8 GB exceeds the RAM recommendation but does not change PostHog's hobby-only support posture. | Get Now |
| ZimaBoard 2 1664 | PostHog hobby deployments with more retained data or co-hosted services. | Larger Docker memory budget, more replay/data retention and additional containers. |
|
16 GB does not convert the hobby deployment into a supported large-scale production architecture. | Get Now |
| ZimaCube 2 Pro | A heavier analytics homelab where PostHog is one of several services. | More storage, queries, replay data and broader service consolidation. |
|
Use stronger hardware for the lab only; above ~100K events/month PostHog recommends moving to Cloud. | 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 PostHog RAM, event volume, storage and the current self-hosting boundary.
How much RAM does self-hosted PostHog need?
The current official PostHog repository recommends 4 GB memory for the open-source hobby deployment.
How many events can self-hosted PostHog handle?
PostHog says open-source deployments should scale to approximately 100,000 events per month, after which it recommends PostHog Cloud.
How many CPU cores does PostHog need?
The current hobby guidance does not publish one universal CPU-core minimum. Ingestion, queries, replay and co-hosted services determine CPU demand.
How much storage does PostHog need?
There is no universal official disk minimum. Events, session replay data, analytics databases, Docker data and backups can grow quickly.
Does PostHog need an SSD?
SSD is not stated as a strict hobby minimum, but SSD-backed persistent analytics storage is a strong practical choice.
Does PostHog need a GPU?
No dedicated GPU is required for normal product analytics, feature flags, web analytics or standard hobby self-hosting.
Can ZimaBoard 2 run PostHog?
Yes for a hobby deployment. The 8 GB model exceeds PostHog's 4 GB memory recommendation; add SSD storage and keep the ~100K-events/month guidance visible.
Should I scale PostHog on ZimaCube instead of using PostHog Cloud?
A larger Zima host can improve a lab deployment, but PostHog itself recommends Cloud after roughly 100K events/month.
What sources informed this PostHog hardware guide?
The guide uses PostHog's current official repository for the hobby-deploy memory and event-volume guidance, plus current Zima product pages for hardware matching.
