Deploying a reverse proxy to PostHog Cloud

A reverse proxy enables you to send events to PostHog Cloud using your own domain.

This means setting up a service to redirect requests from a subdomain you choose (like e.yourdomain.com) to PostHog.

You then use this subdomain as your api_host in the initialization of PostHog instead of us.i.posthog.com or eu.i.posthog.com.

Why do we recommend deploying one?

Using a reverse proxy means that events are less likely to be intercepted by tracking blockers.

You'll be able to capture more usage data without having to self-host PostHog, ensuring you get a complete view of your users.

Deploying a reverse proxy

Using our managed reverse proxy is the easiest way to do this.

It's available as part of our Teams add-on, which includes automatic provisioning, SSO and 2FA enforcement, priority support, and additional collaboration features.

Other documented options for deploying a reverse proxy include:

• AWS CloudFront
• Caddy
• Cloudflare
• Kubernetes Ingress Controller
• Netlify
• Next.js rewrites
• Next.js middleware
• nginx
• Remix
• SvelteKit
• Vercel
• Nuxt
• Pomerium

Best practices

• We require that the proxy sets the Host header to the same host it's calling. Check the guides above on how to do that for several proxies.
• Don't use a subdomain that includes posthog, analytics, tracking, or other similar words which might cause events to be blocked.
• Make sure to pass the proper ui_host parameter when initializing PostHog, so that links to PostHog point to the correct host (like us.posthog.com). This is required for tasks like authenticating the toolbar.

Reverse proxy requirements

If you want to use an alternative reverse proxy that we have not documented, it must meet the following requirements:

- route: e.yourdomain.com/static/*
  reverse_proxy: https://us-assets.i.posthog.com/static/*
  host_header: us-assets.i.posthog.com

- route: e.yourdomain.com/*
  reverse_proxy: https://us.i.posthog.com/*
  host_header: us.i.posthog.com