PostHog Self-Hosted vs. Cloud: Which to Pick

The Real Trade-Off

You've shipped. Users are coming. Now you need to know what they're doing.

PostHog solves that problem. It's a product analytics platform built for developers—not marketing teams. No black boxes. No third-party data brokers. Just raw, honest events flowing into a system you control.

But here's the catch: PostHog comes in two flavors. Cloud or self-hosted. And picking wrong costs you money, time, or both.

This guide cuts through the noise. We'll walk you through the actual decision framework, not the marketing spin. By the end, you'll know which version fits your stage, your infrastructure, and your budget.

Prerequisites: What You Need to Know Before Deciding

Before we dig into the comparison, make sure you have clarity on these three things:

Your current traffic volume. Are you at 1,000 events per month or 100 million? PostHog pricing and infrastructure needs scale with volume. If you're still pre-PMF with minimal events, this decision is easier. If you're scaling fast, it gets harder.

Your infrastructure comfort level. Self-hosting PostHog means running Postgres, Redis, and a few other services. You need someone—maybe you—who can handle Docker, Kubernetes, or basic server ops. If your team is frontend-only and DevOps makes you nervous, cloud is simpler.

Your data privacy requirements. Some founders need data to stay behind their firewall for compliance, customer trust, or competitive reasons. Others don't care. Know which camp you're in.

If you're already thinking about SEO and organic visibility, you'll want to pair your analytics setup with a solid keyword roadmap. Our guide on From Busy to Cited: A Founder's Roadmap From Day 0 to Day 100 covers how to instrument your product with the right metrics from day one.

Step 1: Calculate Your Actual Event Volume

This is where most founders get it wrong. They guess. Don't guess.

What counts as an event in PostHog? Every action—page view, button click, form submission, API call, custom event you track. If you're running a SaaS product with 100 active users and each user generates 50 events per day, that's 5,000 events daily, or roughly 150,000 per month.

How to estimate:

1. Open your current analytics (Google Analytics, Amplitude, Mixpanel, whatever you're using now).
2. Find your monthly page views or events tracked.
3. Multiply by 1.5 to account for events you'll want to track but aren't tracking yet.
4. That's your baseline.

PostHog Cloud pricing is simple: free tier up to 1 million events per month, then $0.00005 per event after that. At 10 million events, you're paying $450 per month. At 100 million, you're at $4,500.

Self-hosted? You pay for infrastructure. A small instance (2 CPU, 4GB RAM) runs about $20-40 per month on AWS, GCP, or DigitalOcean. A medium instance (4 CPU, 8GB RAM) runs $60-100. A large instance (8 CPU, 16GB RAM) runs $150-300.

Here's the math: If you're under 5 million events per month, PostHog Cloud is probably cheaper than self-hosting. If you're over 10 million, self-hosting starts looking better. Between 5-10 million is the gray zone where it depends on your infrastructure costs.

Step 2: Assess Your Infrastructure Readiness

Self-hosting PostHog isn't hard, but it requires baseline DevOps competence. Let's be honest about what that means.

You should self-host if:

• You have someone on your team (even part-time) who's comfortable with Docker and basic Linux.
• You already run infrastructure (servers, databases, load balancers).
• You have a deployment pipeline (GitHub Actions, GitLab CI, or similar).
• You're comfortable patching and updating systems.

You should use PostHog Cloud if:

• Your team is purely frontend/product focused.
• You have no DevOps person and don't want to hire one.
• You want updates and security patches handled automatically.
• You'd rather pay for managed infrastructure than manage it yourself.

Let's be specific about the operational burden. Self-hosted PostHog requires:

• Initial setup: 2-4 hours for a basic deployment. This includes spinning up a server, installing Docker, pulling the PostHog image, configuring environment variables, and setting up a reverse proxy (Nginx or similar).
• Ongoing maintenance: 2-4 hours per month. This includes monitoring disk space (PostHog stores a lot of data), updating the application when new versions ship, patching the underlying OS, and backing up your database.
• Scaling as you grow: If you hit 50+ million events per month, you'll need to split PostHog across multiple machines, set up a proper database cluster, and potentially add a message queue (Kafka or RabbitMQ). This is not trivial.

PostHog Cloud handles all of this for you. Updates happen automatically. Scaling is invisible. You just pay and it works.

If you're trying to move fast and focus on product, cloud buys you time. If you're already deep in infrastructure and want to own your data, self-hosting makes sense.

For founders building SEO infrastructure alongside product analytics, check out our The Free SEO Tool Stack Every Founder Should Set Up Today guide—it covers how to wire up event tracking for organic visibility metrics without adding complexity.

Step 3: Evaluate Data Privacy and Compliance

This one's non-negotiable if it applies to you.

PostHog Cloud: Your event data lives on PostHog's servers, which are hosted on AWS in multiple regions. PostHog signs a DPA (Data Processing Agreement) if you need it for GDPR or similar. Your data is encrypted in transit and at rest. But it's not behind your firewall.

PostHog Self-Hosted: Your data lives on your infrastructure. You control the database. No one from PostHog can access your events without explicit permission. This matters if:

• You're handling healthcare data (HIPAA).
• You're in a regulated industry (finance, legal).
• You have customers who demand data residency (EU-only, for example).
• You're tracking sensitive user behavior and want to minimize exposure.

For most early-stage founders, this isn't a blocker. But if you're selling to enterprises or handling regulated data, self-hosting is often a requirement.

One more thing: if you're tracking user behavior for SEO purposes (which you should be), you'll want to wire up your analytics to understand which content drives engagement. Our Setting Up Google Tag Manager Without Breaking Your Site guide walks through proper event tracking setup without creating data silos.

Step 4: Compare Total Cost of Ownership

Let's do the math for three scenarios.

Scenario A: Early-stage startup, 2 million events/month, no DevOps person

• PostHog Cloud: $100/month (free tier covers 1M, then $0.00005 × 1M = $50, plus some overhead)
• Self-hosted: $40/month (infrastructure) + 4 hours/month of engineering time (at $100/hour = $400) = $440/month
• Winner: Cloud (10x cheaper when you account for time)

Scenario B: Growth-stage startup, 20 million events/month, has a DevOps engineer

• PostHog Cloud: $1,000/month (1M free + $0.00005 × 19M = $950)
• Self-hosted: $150/month (infrastructure, larger instance) + 6 hours/month of maintenance (at $150/hour = $900) = $1,050/month
• Winner: Tie (roughly equivalent; self-hosted wins if you already have DevOps capacity)

Scenario C: Scale-stage startup, 100 million events/month, has infrastructure team

• PostHog Cloud: $5,000/month (1M free + $0.00005 × 99M = $4,950)
• Self-hosted: $400/month (infrastructure, high-availability setup) + 15 hours/month of maintenance (at $150/hour = $2,250) = $2,650/month
• Winner: Self-hosted (50% cheaper, plus you own the data)

The inflection point is usually around 10-15 million events per month. Below that, cloud is cheaper. Above that, self-hosted starts winning.

But time cost is real. If you're a solo founder or a small team, cloud's simplicity has value that doesn't show up in the spreadsheet.

Step 5: Check the Feature Parity

Here's something PostHog doesn't advertise loudly: cloud and self-hosted have different feature sets.

PostHog Cloud has these features:

• Full feature parity with the latest release
• Automatic updates (sometimes you don't want this, but it's safer)
• Advanced features like feature flags, A/B testing, surveys, and session replay
• Managed backups and disaster recovery
• Priority support (paid plans)

PostHog Self-Hosted has:

• Everything in the Cloud version, but you control the release schedule
• The ability to fork and customize the codebase (though PostHog doesn't recommend this)
• Full control over data retention and deletion
• The option to integrate with your own data warehouse

In practice, self-hosted usually lags Cloud by one or two releases. If you're running a 6-month-old version of self-hosted PostHog, you might be missing features that shipped recently. This isn't a deal-breaker, but it's worth knowing.

For the official breakdown, check PostHog's self-host documentation to see the current feature matrix.

Step 6: Review the Operational Reality

Let's talk about what actually happens after you pick.

If you pick PostHog Cloud:

1. Sign up at posthog.com.
2. Generate an API key.
3. Install the PostHog SDK in your product (JavaScript, Python, Node, Go, whatever).
4. Start shipping events.
5. Log in to the PostHog dashboard and watch data flow in.

Time to first event: 30 minutes.

Then what? You set up dashboards, define cohorts, run experiments. PostHog handles the infrastructure. When you need to scale, you just pay more. When PostHog ships a new feature, you get it automatically.

The downside: you're dependent on PostHog's uptime. In 2024, PostHog had a few brief outages. If your product relies on real-time event tracking for critical features (like feature flags), an outage affects you.

If you pick self-hosted:

1. Spin up a server (AWS, GCP, DigitalOcean, your own data center).
2. Install Docker.
3. Pull the PostHog image from GitHub.
4. Configure environment variables (database URL, secret key, etc.).
5. Start the container.
6. Set up a reverse proxy (Nginx) to handle SSL.
7. Install the SDK and start shipping events.

Time to first event: 4-6 hours (if you know what you're doing).

Then what? You monitor your instance. You upgrade PostHog when new versions ship. You manage your database. You handle backups. When you hit scaling limits, you architect a solution (horizontal scaling, database replication, message queues).

The upside: full control. You can customize. You own your data. You're not dependent on someone else's infrastructure.

The downside: you're responsible for uptime, security, and scaling.

Step 7: Make the Decision

Here's a simple decision tree:

Pick PostHog Cloud if:

• You're under 5 million events per month.
• You don't have a DevOps person.
• You want to ship fast and not think about infrastructure.
• You don't have strict data residency requirements.
• You're okay with PostHog's uptime SLA (99.9% for paid plans).

Pick self-hosted if:

• You're over 10 million events per month.
• You have someone on your team who can manage infrastructure.
• You need data to stay behind your firewall.
• You want to minimize per-event costs at scale.
• You're willing to trade operational burden for control.

If you're between 5-10 million events per month: Run the numbers. If you have DevOps capacity, self-hosting probably wins. If you don't, Cloud is simpler.

Once you've picked your analytics stack, wire it up to track the metrics that matter. Our guide on The Quarterly SEO Review: A Founder's Repeatable Process shows how to connect your analytics to organic visibility metrics—so you're not just tracking product events, you're tracking the events that drive growth.

Pro Tips for Cloud Users

Tip 1: Set up event batching. PostHog can batch events before sending them to the server. This reduces network overhead and improves performance. Configure your SDK to batch every 10-50 events or every 5 seconds, whichever comes first.

Tip 2: Use feature flags to control event volume. If you're approaching your Cloud pricing tier, use PostHog's feature flags to disable expensive tracking in production. Keep it enabled in staging for testing.

Tip 3: Archive old events. PostHog Cloud retains data for 7 years by default. If you have compliance requirements, you can configure shorter retention. This doesn't affect your bill, but it's good practice.

Tip 4: Export your data regularly. Even on Cloud, export your event data to a data warehouse (Snowflake, BigQuery, Redshift) for long-term analysis. PostHog integrates with most of them. This gives you a backup and lets you run arbitrary queries.

Pro Tips for Self-Hosted Users

Tip 1: Use managed Postgres. Don't run Postgres in Docker on the same machine as PostHog. Use AWS RDS, GCP Cloud SQL, or DigitalOcean Managed Databases. It's $50-100/month extra, but it saves you from database disasters.

Tip 2: Set up automated backups. Configure your managed database to back up every 24 hours. Keep 30 days of backups. This is non-negotiable.

Tip 3: Monitor disk space. PostHog stores a lot of data. Set up alerts for disk usage. When you hit 80% capacity, you need to plan your next scaling move. Don't wait until you run out of space.

Tip 4: Use environment variables for secrets. Never hardcode API keys or database passwords in your Docker config. Use environment variables or a secrets manager (AWS Secrets Manager, HashiCorp Vault). This is basic ops hygiene.

Tip 5: Set up a staging instance. Before you upgrade PostHog in production, test the upgrade on a staging instance. This prevents surprises.

Warnings: Where Founders Get Burned

Warning 1: Underestimating event volume. Founders often think they're tracking 1 million events per month, then realize it's 10 million once they actually measure. This happens because they forget about background events, automated tracking, or third-party integrations. Measure first, then decide.

Warning 2: Picking self-hosted without DevOps capacity. Self-hosting PostHog without someone who understands infrastructure is a recipe for a broken analytics system. Your database will fill up. Your instance will crash. You won't know how to fix it. If you don't have DevOps, use Cloud.

Warning 3: Forgetting about data egress costs. If you self-host PostHog on AWS and export data to BigQuery (Google Cloud), you pay egress fees. This can add up to hundreds per month. Check your cloud provider's pricing before you commit.

Warning 4: Running out of database capacity. Self-hosted PostHog's database grows with every event. At 100 million events, your Postgres database might be 500GB. Make sure your server can handle it. Plan for growth.

Warning 5: Neglecting security. If you self-host, your instance is exposed to the internet. Use a strong reverse proxy (Nginx with SSL), enable authentication, restrict IP access if possible, and keep your instance patched. A compromised PostHog instance exposes all your user event data.

Integration with Your SEO Strategy

Here's something most founders miss: your analytics choice affects your SEO strategy.

If you're tracking user behavior in PostHog, you should also be tracking which content drives that behavior. Wire up your analytics to understand which blog posts, landing pages, or guides generate the most engaged users. This tells you what to write about next.

Our The Busy Founder's Brief Template for AI-Generated Content shows how to use your analytics to brief AI content generators. If you know that "how to set up X" posts drive 3x more engagement than "why Y" posts, you brief your AI to write more how-tos.

For a complete picture, pair PostHog with Google Analytics. PostHog tells you what users do inside your product. Google Analytics tells you what they do on your website. Together, they show you the full funnel from organic traffic to product adoption.

Also, check out Chrome Extensions Every SEO-Curious Founder Should Install—it includes tools to audit your site's event tracking setup and make sure you're not missing critical metrics.

Comparison with Alternatives

PostHog isn't the only product analytics platform. Let's quickly compare:

Amplitude: Cloud-only, expensive ($995+/month for most founders), great UI, strong cohort analysis. No self-hosted option. If you're already using Amplitude and considering PostHog, you're probably looking for cost savings. PostHog is usually 50-70% cheaper at the same event volume.

Mixpanel: Cloud-only, similar pricing to Amplitude, strong for mobile analytics. Again, no self-hosted option. Similar cost comparison to Amplitude.

Segment: A data pipeline tool, not analytics. It collects events and sends them to multiple destinations (PostHog, Amplitude, Mixpanel, data warehouses, etc.). Use Segment if you want flexibility. Use PostHog directly if you just need one analytics platform.

For a deeper comparison, KISSmetrics vs PostHog: Managed vs Self-Hosted breaks down the trade-offs between managed and self-hosted platforms.

If you're looking for fully self-hostable alternatives with cloud parity, check out PostHog Alternatives: Fully Self-Hostable Options. But honestly, PostHog's open-source model is hard to beat—you get a fully-featured platform either way.

The Hacker News Perspective

If you want to see what real developers think, Hacker News discussions on PostHog are worth reading. The consensus: PostHog's self-hosted option is genuinely useful, Cloud is solid but pricey at scale, and the community is helpful.

One recurring theme: founders who self-host often mention that owning their data was worth the operational overhead. Founders on Cloud often mention that simplicity was worth the cost. Both are valid.

Timeline: When to Revisit This Decision

Your choice today might not be right in 6 months. Here's when to revisit:

Every quarter: Check your event volume. If you've grown 3x, recalculate the math. You might have crossed the inflection point where self-hosting makes sense.

When you hire DevOps: If you're on Cloud and you hire a DevOps engineer, revisit self-hosting. You now have the capacity to manage it.

When your bill hits $500/month: At this point, self-hosting is worth serious consideration. The operational burden is still there, but the cost savings are real.

When you hit compliance requirements: If you suddenly need HIPAA or SOC 2, self-hosting might become necessary. Plan for this before it's urgent.

If you're building a sustainable SEO strategy alongside your product, you'll want to revisit your analytics setup as you scale. Our The Compounding Founder: SEO Habits That Pay Off in Year Two guide covers how to evolve your analytics and content strategy as you grow.

Setting Up Your First Analytics Events

Once you've picked your platform, here's what to track:

Core events:

• page_view — Every page load (this is automatic in most SDKs)
• signup — User creates an account
• login — User logs in
• feature_used — User clicks a key button or uses a key feature
• error — Something breaks
• conversion — User completes your primary goal (purchase, subscription, etc.)

Add properties to every event:

• user_id — Unique identifier for the user
• timestamp — When the event happened (automatic)
• url — Current page URL
• referrer — How the user got here
• device_type — Mobile, tablet, desktop
• country — User's location

Start with these. Don't over-engineer. You can add more events and properties later.

For a complete setup guide, PostHog's official documentation has SDKs and integration guides for every language and framework.

Conclusion: Ship, Then Decide

Here's the truth: you probably don't need to overthink this.

If you're early-stage (under 5 million events/month) and don't have a DevOps person, use PostHog Cloud. It's $100-500/month. It works. Move on to building your product.

If you're scaling (over 10 million events/month) and have infrastructure capacity, self-host. You'll save money and own your data.

If you're in the middle, run the numbers. The decision is usually clear once you do.

The bigger mistake is not tracking events at all. Some founders ship products and never instrument them. They have no idea what users are doing. They guess. They build the wrong things. Don't be that founder.

Pick a platform—Cloud or self-hosted, doesn't matter which—and start shipping events today. You can always migrate later. Migration is annoying but doable. Not tracking is a permanent mistake.

Once you've got analytics running, wire it into your content strategy. Track which blog posts and landing pages drive the most engaged users. Use that data to brief your AI content generator. Build a content system that compounds. Our SEO Bootcamp for Busy Founders: 14 Days, 14 Wins walks through this exact process—analytics, content, and organic visibility working together.

Ship fast. Track everything. Let the data tell you what's working. That's the founder's way.

Quick Reference: Decision Checklist

• Calculated your actual monthly event volume
• Assessed your team's DevOps capacity
• Reviewed your data privacy requirements
• Ran the TCO math for Cloud vs self-hosted
• Checked feature parity between versions
• Decided: Cloud or self-hosted?
• Set up your first analytics instance
• Configured core events and properties
• Wired analytics into your content strategy
• Set a calendar reminder to revisit this decision in 3 months

You're ready. Ship it.