Analytics guide
Self-Host PostHog: Read the Limits Before You Deploy
Decide whether PostHog’s advanced hobby deployment fits your team before accepting its resource, retention, backup, and support burden.
Published and reviewed by OpenAlt · September 22, 2026
PostHog self-hosting is a reasonable choice only when data control matters more than convenience and your team can own a small production-like system. The official FOSS path is an advanced hobby deployment: plan for at least 4 GB RAM, roughly 100k events/month, and no support or guarantees. Test fit before committing.
Table of Contents
- Hard truth
- When a hobby deploy fits
- Resource and ops preflight
- Setup and workflow
- Domain, TLS, and ingestion verification
- Retention, backups, and rollback
- Exit criteria and next step
- Frequently Asked Questions
Hard truth
Self-hosting transfers operational responsibility to your team. You control where analytics data is stored, but you also own the host, deployment, domain, HTTPS, data lifecycle, backups, upgrades, and recovery.
The official FOSS README calls the self-hosted route an advanced hobby deployment, recommends 4 GB of RAM, and gives rough guidance of 100k events per month. It also says self-hosted users receive no support or guarantees. That is not an implied enterprise support contract. Read the official FOSS README and the self-host deployment disclaimer before choosing it.
Self-host when data control, local ownership, or experimentation outweighs maintenance. Choose a managed option when reliable analytics matters more than infrastructure control.
When a hobby deploy fits
A hobby deploy fits when the workload is bounded, the owner is named, and occasional operational work is acceptable. It is a plausible match when:
- Your team wants tighter control over analytics data location and access.
- Initial workload is comfortably within the rough 100k-events-per-month guidance.
- Someone owns DNS, TLS, upgrades, backups, and incident response.
- You can validate ingestion before sending important production traffic.
- A temporary outage would be inconvenient but not business-critical.
Reconsider it when no person owns the deployment, the machine only barely meets the 4 GB recommendation, event volume is already beyond the rough hobby boundary, backups cannot be restored, or stakeholders expect vendor-style support and guarantees.
Use the PostHog product documentation to confirm the capabilities you need belong in the planned deployment. “Open source” does not remove capability, privacy, or operations decisions.
Resource and ops preflight
Proceed only when the host and operating process have headroom for failure, maintenance, and troubleshooting—not merely initial installation.
| Area | Proceed when | Stop or reconsider when |
|---|---|---|
| Memory | At least 4 GB RAM is available with practical headroom | 4 GB is the entire machine |
| Volume | Traffic is roughly within 100k events/month | Growth is already beyond the rough guidance |
| Ownership | One person or team owns operations | Responsibility is undefined |
| Data | Retention and access rules are understood | Sensitive data may be collected accidentally |
| Recovery | Backups and restore checks are planned | There is no tested recovery path |
| Support | The team accepts no support or guarantees | Stakeholders expect enterprise-style assistance |
Before installation, define the hostname, confirm DNS can point to the host, and confirm HTTPS and certificate renewal can be maintained. Choose the application that will send the first low-risk test events. Review what should never be captured, assign an operational owner, record where configuration, secrets, and persistent data will be backed up, and define when to migrate to cloud or another tool.
The official data management guidance should shape collection and retention.
Setup and workflow
The official one-line installer is the documented starting point for the hobby path. Use the current command from PostHog’s instructions rather than copied internals that may change.
A practical workflow is:
- Choose a host with at least the recommended 4 GB RAM and operational headroom.
- Read the current self-host documentation immediately before installation.
- Run the official one-line installer exactly as documented.
- Record the hostname, administrator access method, persistent storage locations, and configuration secrets.
- Configure the public domain and HTTPS before sending meaningful production data.
- Confirm the interface is usable.
- Instrument one low-risk application or environment.
- Verify test events and their expected properties.
- Document backup, restore, upgrade, and rollback procedures.
- Expand traffic only after verification passes.
An installer can simplify first deployment; it does not eliminate maintenance. Store the official instructions used with the team’s operational documentation.
Domain, TLS, and ingestion verification
A stable hostname and working HTTPS are launch requirements. Before production traffic, verify that DNS resolves the intended host, HTTPS loads without certificate warnings, the application uses that hostname, the deployment survives a restart or routine maintenance, and certificate renewal has an owner.
Basic shell checks are:
dig +short analytics.example.com
curl -I https://analytics.example.com
Replace the example hostname with the real one. These checks confirm name resolution and a reachable HTTPS response; they do not prove event ingestion.
Send a low-risk test event and confirm it appears with the expected project, timestamp, and properties. Send a second event through the same application path to confirm repeatability. Compare the application’s analytics configuration with project settings, and check for accidental sensitive fields using the official data guidance.
Retention, backups, and rollback
Retention and backups solve different problems: retention limits what you intend to keep, while backups determine whether you can recover from an operational mistake or failed change.
Set a written retention policy before broad rollout. Decide what product data is necessary, what should be excluded, and who may access it. Apply the relevant settings using current documentation and review them after instrumentation changes. The PostHog data documentation is the reference for collected data and related decisions.
Back up persistent application data and configuration using the method appropriate to your installation. Protect secrets separately, restrict access to backup copies, record frequency and retention, and perform a restore check. Keep the last known-good deployment details with the restore notes.
Define recovery before upgrading. Rollback may mean restoring a verified backup or reverting the documented deployment state. Do not improvise by deleting data or changing several variables at once. Preserve evidence of the failed change, restore the known-good state, and repeat HTTPS and ingestion checks before reopening traffic.
Exit criteria and next step
Move to cloud or another tool when the deployment’s burden exceeds the value of controlling it. Consider exiting when event volume is no longer comfortably within the rough hobby guidance, no owner can provide reliable attention, restore testing fails, backups are incomplete, TLS or upgrades repeatedly break, or stakeholders require support and guarantees that self-hosting does not provide.
Cloud can remove much of the infrastructure work your team would otherwise own. Self-hosting can remain the better choice when data control is decisive and the operating model is realistic. Revisit the tradeoff when usage, staffing, or data sensitivity changes.
For the matching project overview, inspect PostHog on OpenAlt. Compare adjacent options in the analytics directory, and review the difficulty methodology to understand how operational complexity is assessed.
Frequently Asked Questions
Is PostHog self-hosting supported?
PostHog’s official FOSS README presents the self-hosted path as an advanced hobby deployment with no support or guarantees. Treat the documentation as the deployment reference, not an enterprise support commitment. Read the self-host disclaimer before launch.
How much RAM does PostHog self-hosting need?
The official FOSS README recommends 4 GB of RAM for the self-hosted hobby deployment. That is a planning baseline, not a promise that every workload will perform identically. Leave practical headroom and reassess as traffic grows.
What happens above 100k events?
The official README describes roughly 100k events per month as hobby-scale guidance. Above that point, reassess capacity, operational risk, and whether self-hosting still fits. Treat the figure as a decision boundary, not a guaranteed hard limit.
Is cloud safer for a small team?
Cloud can be safer operationally because it reduces infrastructure work, but it does not eliminate privacy, access, or vendor-risk decisions. Self-hosting may fit when data control is the priority and the team can maintain backups, updates, TLS, and recovery.
What should be tested before launch?
Test the public hostname, HTTPS, repeatable event ingestion, expected event properties, backup availability, and restoration procedure. Start with a low-risk application or environment, then expand traffic only after those checks pass.