Managed reverse proxy

PostHog's managed reverse proxy routes traffic through our infrastructure. We handle SSL certificates, routing, and maintenance automatically.

This option is free for all PostHog Cloud users. You just need access to your domain's DNS settings.

Setting up during onboarding?

If you're onboarding a web-based product like Web Analytics, Surveys, or LLM Analytics, you'll be guided through managed proxy setup as part of the onboarding flow. The steps below are for setting it up manually from the organization settings.

  1. Create your proxy

    1. Go to organization proxy settings
    2. Click new managed proxy
    3. Enter a subdomain you control. For example, if your app runs on myapp.com, use yoursubdomain.myapp.com
    Before you start

    Choose a neutral subdomain that doesn't include words like analytics, tracking, telemetry, posthog, or ph. Ad blockers target these terms. If ad blockers block your domain, the proxy won't achieve its intended effect.

  2. Create a DNS record

    Go to your DNS provider and create a new CNAME record:

    1. Set the Name to your chosen subdomain (just the subdomain part, like yoursubdomain)
    2. Set the Target to the proxy domain PostHog generated in the previous step. You'll see it in your proxy settings, it looks like 4854cf84789d8596ad01.proxy-us.posthog.com
    3. Save the record
    Disable DNS provider proxy features

    If you're using a DNS provider like Cloudflare that offers proxy options (orange cloud), make sure the proxy is disabled (gray cloud) for this CNAME record. Enabling the proxy at your DNS provider may interfere with PostHog's managed reverse proxy functionality and SSL certificate provisioning.

  3. Wait for propagation and provisioning

    Your proxy status will change from waiting → issuing → live. This typically takes 2-5 minutes for a new record, but can take up to 30 minutes if DNS propagation is slow. (Propagation can take a few hours if you're making changes to an existing CNAME.)

    PostHog will automatically detect your DNS record and provision an SSL certificate. No further action needed.

    Note: If your proxy stays in issuing for more than 30 minutes, see troubleshooting.

  4. Update your PostHog SDK

    Update your PostHog initialization to use your new subdomain:

    posthog.init('<ph_project_token>', {
      api_host: 'https://yoursubdomain.myapp.com',
      ui_host: 'https://us.posthog.com'
    })

    Replace yoursubdomain.myapp.com with your actual subdomain, and provide your project token.

    Always set both api_host (your proxy) and ui_host (PostHog's actual domain) so features like the toolbar work correctly.

  5. Verify your setup

    Checkpoint

    Confirm events are flowing through your proxy:

    1. Open your browser's developer tools and go to the Network tab
    2. Trigger an event in your app, like a page view
    3. Look for a request to your proxy subdomain (e.g., yoursubdomain.myapp.com)
    4. Verify the response is 200 OK
    5. Check the PostHog app to confirm events appear

    If you see errors or events aren't appearing, see troubleshooting.

FAQ

Why does my managed proxy stay in "erroring" state with Cloudflare?

If you're using a Cloudflare Enterprise zone with zone hold enabled, the managed reverse proxy won't work. Zone holds prevent external services from provisioning SSL certificates or verifying DNS for domains in your zone.

You have two options:

  1. Set up a self-hosted proxy instead: Use Cloudflare Workers to create your own reverse proxy. This works with zone holds enabled since you're configuring everything within your own Cloudflare account.

  2. Disable zone hold (not recommended): Zone holds are typically enabled for security reasons. Disabling them may expose your domain to certain risks. Only consider this if you understand the security implications for your organization.

For most users with Cloudflare Enterprise, option 1 (setting up your own Cloudflare Worker proxy) is the recommended approach.

For EU Cloud, is managed reverse proxy traffic guaranteed to terminate only at EU Cloudflare edges?

Not strictly guaranteed, but in practice this is usually the case. Cloudflare uses anycast routing to terminate connections at the data center closest to the end user, so requests from users in Europe almost always land on EU edges. There are two caveats:

  • If your user is physically outside Europe, their request will terminate at a non-EU edge.
  • If the nearest Cloudflare data center is overloaded or unavailable, traffic may be routed to another region.

We do not enable Regional Services or the Data Localization Suite on the managed reverse proxy, so EU-only edge termination is not contractually enforced.

That said, the managed reverse proxy is designed so that no request content is stored at the edge, regardless of which data center terminates the connection:

  • The Cloudflare Workers we use to forward traffic to our ingestion pipeline do not log requests.
  • Request caching is not enabled.
  • Cloudflare has confirmed to us that they do not retain request logs for this traffic either.

Once traffic reaches PostHog, it is ingested into the region you selected (EU or US Cloud). If strict EU-only termination at the edge is a hard requirement for your compliance posture, we recommend setting up a self-hosted proxy on infrastructure you control instead.

Community questions

Was this page useful?

Questions about this page? or post a community question.