# Problem Users today are forced to use the Product Analytics stack that is connected directly to GitLab.com. This makes it easy to get started, but takes some control and flexibility away from users. Users may wish to host their own Snowplow, ClickHouse, Cube.dev deployments on their infrastructure as part of utilizing existing resources they already have, to have more control over costs, meet unique scalability requirements for their organization, utilize bespoke data retention strategies, as a few examples. # Proposal Provide configuration options that allow users to specify their own Snowplow, ClickHouse, and Cube.dev deployments that GitLab will then use for all Product Analytics workflows, rather than the cluster that GitLab.com is already configured with. - There should be no difference in the user experience for dashboards and reporting because of using a user-provided cluster instead of the GitLab-provided one. User-provided clusters should be specifiable on a **per-project** basis. - Certain users may wish to use different clusters per-app, so allowing this setting at a group-level only would not be ideal for them. ## Example Configurations/Illustrations | .com (Managed Shared) | Dedicated (Managed Private) | Self-managed | |---|---|---| |  |  |  | ## Tiering This should be available to users that are entitled to Product Analytics features # Open questions 1. Could we (GitLab) have our GitLab.com-provided cluster as the default values that can then be overridden? 1. Can we move the existing [admin-view settings](https://gitlab.com/gitlab-org/gitlab/-/issues/375577) to the project-level as the way to address this? 1. _fill in other questions_