mirror of
https://github.com/BillyOutlast/posthog.com.git
synced 2026-02-04 03:11:21 +01:00
15c925b43d
Co-authored-by: Cory Watilo <corywatilo@gmail.com> Co-authored-by: Eli Kinsey <eli@ekinsey.dev> Co-authored-by: Lucas Faria <12522524+lucasheriques@users.noreply.github.com> Co-authored-by: Ben White <ben@posthog.com> Co-authored-by: Juraj Majerik <juro.majerik@gmail.com> Co-authored-by: Rafael Audibert <32079912+rafaeelaudibert@users.noreply.github.com>
71 lines
3.2 KiB
Plaintext
71 lines
3.2 KiB
Plaintext
---
|
|
title: Deploying a reverse proxy to PostHog Cloud
|
|
sidebar: Docs
|
|
showTitle: true
|
|
---
|
|
|
|
import ProxyPathNamesWarning from './_snippets/proxy-path-names-warning.mdx'
|
|
|
|
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](/docs/advanced/proxy/managed-reverse-proxy) is the easiest way to do this.
|
|
|
|
It's available as part of our [platforms add-ons](/platform-packages), 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](/docs/advanced/proxy/cloudfront)
|
|
- [Caddy](/docs/advanced/proxy/caddy)
|
|
- [Cloudflare](/docs/advanced/proxy/cloudflare)
|
|
- [Kubernetes Ingress Controller](/docs/advanced/proxy/kubernetes-ingress-controller)
|
|
- [Netlify](/docs/advanced/proxy/netlify)
|
|
- [Next.js rewrites](/docs/advanced/proxy/nextjs)
|
|
- [Next.js middleware](/docs/advanced/proxy/nextjs-middleware)
|
|
- [nginx](/docs/advanced/proxy/nginx)
|
|
- [node](/docs/advanced/proxy/node)
|
|
- [Railway](/docs/advanced/proxy/railway)
|
|
- [Remix](/docs/advanced/proxy/remix)
|
|
- [SvelteKit](/docs/advanced/proxy/sveltekit)
|
|
- [Vercel](/docs/advanced/proxy/vercel)
|
|
- [Nuxt](/docs/advanced/proxy/nuxt)
|
|
- [Pomerium](/docs/advanced/proxy/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](/docs/libraries/js/config) 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.
|
|
- <ProxyPathNamesWarning />
|
|
|
|
## Reverse proxy requirements
|
|
|
|
If you want to use an alternative reverse proxy that we have not documented, it must meet the following requirements:
|
|
|
|
```yaml
|
|
- 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
|
|
```
|
|
|
|
<CalloutBox icon="IconWarning" title="Beware of size limits" type="caution">
|
|
Some systems have size limits (e.g. AWS WAF defaults to 8kb) which can cause problems if they are used as or with a
|
|
reverse proxy. PostHog events can be up to 1MB and session recordings can be up to 64MB per message, so you may need
|
|
to adjust your limits.
|
|
</CalloutBox>
|