Handle multiple environments of the same product within one PostHog project

[Twixes]

Is your feature request related to a problem?

Currently if you're running your software in separate environments, e.g. the classic: development/staging/production, and are instrumenting analytics within it, you have two options of using PostHog:

1. Keep all data within one project and only label events with an environment (or similar in idea) property.
   This however has the downside of forcing you to add the appropriate event property everywhere, and may mess up person data.
2. Create separate projects for each environment. This provides total separation of data, but creates multiple places to set up analytics (e.g. actions, dashboards, feature flags) for the same product, which is a lot of work with flimsy results.

Describe the solution you'd like

Switching between environments within a project, keeping the setup the same, only with completely separate data.

Or… something else? Ideas welcome!

Additional context

Multiple users have been asking as about this exact same use case and so far our solutions have always been underwhelming due to the above issues.

Thank you for your feature request – we love each and every one!

[yakkomajuri]

+1 for this from a user

[Twixes]

The reason we haven't found a need for this while dogfooding is because we deploy to production continuously without staging, and in development we just run the local instance with SELF_CAPTURE. This is clearly a pain point for a number of our users though.

Probably the best solution would be an intraproject environment switch. Sentry has solved this quite well:

[MrTin]

Pitching in on our use case and hoping it can be helpful, but I don't have a strong opinion on how to go about other than just being able to separate the environments when necessary.

For analytics services -- I tend to setup an environment for dev+staging and one separate for production. The reason behind this is that in my experience, we typically use the dev+staging environment to manually make sure events are pushed and received with the correct name and the properties expected. We might play around with a funnel and set that up to verify it works but we wouldn't really make any use of the data or setup actions other than for testing.

Production is where we make it important to keep data clean from testing, where either developers or analysts go in and setup actions, dashboards, funnels etc. that we actually use every day.

In contrast, for exception tracking (Sentry/AppSignal etc.), I would setup a development, staging and production separately, keeping notifications disabled for dev and enabled for staging + prod.

[buwilliams]

Do you know of a way to achieve this without touching every query?

[EDsCODE]

I would suggest that @Twixes's (2) option is actually sufficient. Wrapping a separate project as a "test" environment would be fine because there would be some unduplicated entities such as actions, feature flags, dashboards but you'll be able to clearly recognize you're on your test environment as @paolodamico has previously mentioned. You'll also be able to clear test data freely.

If needed, I think we should add a "sync" option in the test instance that gives the option to sync the test environment with the production environment entities after the fact. This way you can clear your test instance and reload as needed

[buwilliams]

Since we already support multiple projects, I'm thinking we could extend this feature by:

• Create multiple environments for the user with a button click.
• Sync settings across environments when we create it and with button click.
• Provide a sync feature that allows a user to copy settings from another environment.

[paolodamico]

100% aligned with @EDsCODE's approach (it's what we've been discussing offline). Basically this would only be a frontend change, where we treat a special project as a test project and instead of showing the project in the regular project list, we have a test/live switch that makes it more clear. Let me know if you want some input on the design for this.

Also, to avoid confusion with internal users filters and such I would call this very explictly something like "Sandbox" mode.

In addition a few nice things that could make the experience better:

• +1 on @EDsCODE/@Twixes's sync option
• Have the API key for the test project start with "test_" or "sandbox_" to avoid any confusion there.

[paolodamico]

To your last comment @buwilliams, at first glance I think it would be better to be explicit about a test environment. I think having multiple environments could potentially cause more confusion or dilute the impact of this, but happy to discuss further.

[buwilliams]

Should we create a path around multiple projects for self-hosted being a contact sales feature?

[paolodamico]

I think we already have that, we take them to the pricing page, but if not, makes sense! Though having a test env/project I would not consider a premium feature. I'd still allow users to have the demo project, the test project and the default project.

[buwilliams]

Right exactly if I'm understanding you. We should allow people to have access to a default project AND a test project so that they get multiple environment support for free? I don't yet understand how the paywall works.