In some architectures, a single website needs to send analytics events to multiple PostHog projects. This situation commonly appears in the following scenarios:

• Environment separation (development, staging, production)
• Multi-tenant platforms
• Data ownership separation between teams or companies
• Migrations between PostHog projects
• Sending operational data to one project and product analytics to another

PostHog supports this setup by allowing multiple instances of the JavaScript SDK to run simultaneously on the same website.

How Multiple PostHog Instances Work

PostHog allows initializing multiple instances of the SDK using the third parameter of the initialization function. This parameter defines the instance name.

Each instance is independent and sends data to a different PostHog project using a different API key.

Conceptually:

• Default instance sends events when calling the standard capture method.
• Named instances send events when calling capture on the specific instance.

This means events are not automatically sent to all instances. You must explicitly send the event to each instance.

Important Considerations

1. Disable Automatic Capture

If you run multiple instances and leave automatic capture enabled, PostHog may automatically send pageviews, clicks, and other events to multiple projects, which can create duplicated or inconsistent data.

It is recommended to disable automatic capture and send only the events you explicitly define.

2. Use the Same distinct_id

If you want the same user to be recognized in both projects, you must use the same distinct identifier in both instances. Otherwise, the same user will appear as different users in each project.

3. Prefer Backend Duplication for Critical Events

If the events are business-critical (payments, signups, conversions), a better architecture is:

1. Frontend sends the event once to your backend.
2. Backend sends the event to PostHog Project A.
3. Backend sends the event to PostHog Project B.

This approach provides:

• Retries
• Validation
• Logging
• Idempotency
• Better data governance

When This Architecture Is Recommended

Use multiple PostHog projects when:

• You need strict data separation
• Different teams own different analytics
• You are migrating between projects
• You want to separate product analytics from marketing analytics
• You manage analytics for multiple clients from the same platform

Do not use multiple projects if you only need more properties or more event attributes. In that case, a single PostHog project with more event properties is the correct design.

Conclusion

PostHog supports sending events from one website to multiple projects by running multiple SDK instances. However, events are not automatically duplicated; you must explicitly send them to each instance. For robust architectures, especially when events are critical, duplicating events from the backend using the PostHog Capture API is the most reliable approach.