How to set up self hosted PostHog for enterprise data privacy

If you’re reading this, odds are you want product analytics, but you’re not wild about sending customer data to someone else’s cloud. Maybe you’ve got legal, compliance, or just plain common sense reasons to keep things in-house. Whatever your reason, you want to self-host PostHog and put enterprise data privacy front and center. This guide is for you.

No hype, no hand-waving—just the steps, pitfalls, and a little real talk about what’s actually worth your time.

Why Self-Host PostHog?

There are plenty of analytics tools out there, but most are cloud-based, and that means your data lives on someone else’s servers. If you work in finance, healthcare, or anywhere with strict privacy rules, that’s a non-starter. Running PostHog yourself gives you:

  • Full control over data: No third-party snooping, no surprise data sharing.
  • Custom retention policies: Delete or anonymize data on your schedule, not somebody else’s.
  • Compliance flexibility: GDPR, HIPAA, or your own internal requirements—you decide.

But let’s be honest: it’s more work than signing up for a SaaS. You’ll need some technical chops and a willingness to deal with updates, backups, and the occasional head-scratcher.

Step 1: Understand What You’re Getting Into

Before you start, ask yourself:

  • Do you have a team (or at least one savvy admin) to manage this?
  • Are you OK with handling your own security, patching, and scaling?
  • Do you have a real need to self-host? (If it’s just paranoia, make sure it’s justified—sometimes SaaS is actually fine.)

If you’re still in, let’s do it.

Step 2: Choose Your Hosting Environment

Self-hosting PostHog isn’t a one-click install. You’ll need:

  • A cloud server (AWS, GCP, Azure, or a privacy-focused provider like Hetzner)
  • OR on-prem hardware (more privacy, but more headaches—think power, cooling, and disaster recovery)
  • Docker & Docker Compose (PostHog’s recommended way)
  • Decent specs (at least 4 CPUs, 8GB RAM for small setups; more for heavy traffic)
  • A domain name (for SSL and ease of use)

Pro tip: Don’t cheap out on hardware. Analytics can get resource-hungry fast, especially if you turn on all the bells and whistles.

Step 3: Set Up the Basics

3.1. Install Docker & Docker Compose

Most PostHog deployments use Docker. On Ubuntu, you’d run:

bash sudo apt update && sudo apt install docker.io docker-compose -y sudo systemctl enable --now docker

Test it with docker --version and docker-compose --version.

3.2. Clone the PostHog Repo

This gets you the right Docker Compose file and a sample environment config.

bash git clone https://github.com/PostHog/posthog.git cd posthog/deployment/docker-compose

3.3. Prepare Your Environment Variables

Copy .env.example to .env and set up:

  • POSTHOG_SECRET: Generate something strong (openssl rand -hex 32)
  • Database passwords: Use strong, unique passwords
  • SITE_URL: Set this to your domain with https://

Don’t skip this—weak secrets are a privacy disaster waiting to happen.

Step 4: Get Your Data Stack Right

PostHog uses several components:

  • PostgreSQL for the main database
  • ClickHouse for event storage (much faster than just Postgres)
  • Redis for caching and queues
  • Optional: Kafka, Celery, and plugins for scale

The default Docker Compose spins up all of these. For enterprise use, don’t run them all on a single server unless you’re just testing. Use managed databases or separate VMs/containers for better security and performance.

What works: Running ClickHouse and Postgres separately, with backups and monitoring.

What doesn’t: Jamming everything onto a $5 VPS and hoping for privacy or uptime.

Step 5: Launch PostHog

Spin up the stack:

bash docker-compose up -d

Check the logs for errors:

bash docker-compose logs -f

If it comes up clean, you can hit your server’s IP (or domain) in a browser and see the setup screen.

Step 6: Lock Down Security

This is where a lot of “enterprise” guides get fluffy. Here’s what matters:

6.1. SSL Is Not Optional

  • Use Let’s Encrypt for a free, legit SSL cert.
  • Terminate SSL at a reverse proxy (nginx, Traefik, or Caddy).

Sample nginx config:

nginx server { listen 443 ssl; server_name your-domain.com;

ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;

location / {
    proxy_pass http://localhost:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

}

6.2. Firewall Everything

  • Only expose necessary ports (usually 443 and maybe 80 for certbot).
  • Block all database and admin ports from the public internet.

6.3. Use Strong Passwords & Rotate Secrets

  • Store secrets in a password manager, not in plain text files.
  • Change them periodically.

6.4. Keep Everything Updated

  • Patch your OS, Docker, and PostHog images regularly.
  • Set a calendar reminder—this stuff gets forgotten fast.

Step 7: Configure PostHog for Privacy

Out-of-the-box, PostHog is pretty good, but you’ll want to tune it.

7.1. Turn Off Unnecessary Tracking

  • Disable IP address collection if you don’t need it.
    • In PostHog settings: Project Settings > Anonymize IP addresses
  • Don’t collect user emails or PII unless truly needed.

7.2. Data Retention

  • Set up retention rules to automatically delete old data.
    • In PostHog: Data Management > Retention

7.3. Access Controls

  • Use strong, unique admin passwords.
  • Limit who gets access—no need for half the company to see raw analytics.
  • Enable two-factor authentication (2FA) for all accounts.

7.4. Audit Logs

  • Periodically check who’s logging in and what they’re doing.
  • PostHog has basic audit logging—use it.

Ignore: Fancy plugin marketplaces unless you’ve vetted the code. Third-party plugins can punch holes in your privacy.

Step 8: Backups and Monitoring

Self-hosting means you’re on the hook for disaster recovery.

  • Automate database backups (both Postgres and ClickHouse).
    • Use tools like pg_dump and ClickHouse’s built-in backup options.
    • Store backups offsite and encrypted.
  • Monitor resource usage (CPU, RAM, disk space).
    • Use something like Prometheus, Grafana, or plain old htop if you’re scrappy.
  • Set up alerts for downtime, failed backups, or weird spikes.

Pro tip: Test your backups by restoring them to a separate environment. A backup you’ve never tested isn’t a backup.

Step 9: Keep It Private—For Real

  • Don’t send debug info or “anonymous usage stats” back to PostHog unless you’re OK with it.
    • You can opt out in the settings.
  • Review your own privacy policy—make sure it matches what you’re actually doing.
  • Train your team on what data is OK to collect and share.
  • Stay up to date with privacy laws in your region (GDPR, CCPA, etc.).

What to Skip

  • Enterprise add-ons you don’t need: Don’t get upsold on features you’ll never use.
  • Overcomplicated multi-cloud deployments: Unless you have real regulatory requirements, keep it simple.
  • Chasing 100% “zero trust” perfection: Focus on practical, high-impact steps first.

Wrapping Up

Self-hosting PostHog for enterprise privacy isn’t rocket science, but it does take diligence. Don’t try to be perfect out of the gate—get the basics right, document your setup, and iterate as you go. Most privacy breaches come from sloppiness, not superhackers. Keep it tight, keep it simple, and your users will thank you (even if they never know).

Good luck—and don’t forget to test those backups.