Operate: Evaluate and prepare GitLab Orbit delivery
## Problem statement To drive adoption of [GitLab Orbit (AKA GKG)](https://docs.gitlab.com/orbit/), we want to deliver Orbit and its dependency components to self-managed customers. Orbit relies on the following external services: | Name | License | Summary | Cloud-Native Delivery Options | |---|---|---|---| | ClickHouse | Apache 2 | A column-oriented SQL database management system (DBMS) designed for online analytical processing (OLAP) | [SaaS](https://clickhouse.com/docs/getting-started/quick-start/cloud), [Helm chart](https://clickhouse.com/docs/use-cases/observability/clickstack/deployment/helm), [K8s Operator](https://clickhouse.com/docs/clickhouse-operator/overview) | | NATS | Apache 2 | A stateful publish/subscribe message-oriented middleware | [Helm chart](https://github.com/nats-io/k8s) | | Siphon | MIT (GitLab-owned) | A tool for replicating data from PostgreSQL to ClickHouse | [Helm chart](https://gitlab.com/gitlab-org/analytics-section/platform-insights/siphon-helm-charts) | To improve the initial experience and ensure a good customer journey, we want to explore shipping GKG and all of its dependencies to Cloud Native customers. Currently, the GitLab chart and Operator do not ship production-ready third-party components, with the exception of stateless networking components (Ingress and Gateway API controllers). Not shipping stateful third-party components was an intentional decision due to operational concerns around managing storage, backup/restore, and HA deployments of such components, particularly for PostgreSQL. ## DRI @clemensbeck ## Acceptance Criteria - [x] Prepare a chart that bundles all GKG dependencies, which is: - Consumable through OAK and the GitLab chart - Capable of deploying the components in a production-ready and secure fashion - Usable for other components (DIP, AR, AI Gateway, ...) - [x] Prepare a MR to wire GitLab chart, GKG, and the dependency stack to base the evaluation on - [x] Orbit was integrated into several setups: Caproni, Operator Bridge (at r+d summit as a PoC), and into crete - [x] Evaluate and document potential future challenges related upgrade behaviors, backup and restore, and long-term maintainability - [x] Document and demo the results to enable making a decision if bundling GKG and it's deps is feasible - [x] Summary of https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/20596+s: 1. NATS/CH won't be distributed as part of DIP and Orbit 1. Siphon and Orbit will be delivered as fully independent charts 1. Siphon and Orbit will not be subcharts of GitLab chart; Instead they will be deployed as independent releases next to GitLab chart. This approach is OAK compatible. - [x] Potential follow-up issues: - [~] Merge the GKG and dependency stack integration into GitLab chart and OAK - [x] Document the decisions, discussions, potential future challenges in ADRs --- <!-- STATUS NOTE START --> ## Status 2026-08-18 :clock1: **total hours spent this week by all contributors**: 10 :status: **TL;DR**: Core deliverables complete, should be good to close. :tada: **achievements**: - Siphon now has a mechanism to wait for GitLab migrations. :issue-blocked: **blockers**: No blockers. :arrow_forward: **next**: - Close discussion with Dedicated and feature teams on possibility to NATS and ClickHouse configuration between Dedicated and Self Managed. If this yields follow-up issues, we should track them as part of https://gitlab.com/groups/gitlab-com/gl-infra/gitlab-dedicated/-/work_items/915 or https://gitlab.com/groups/gitlab-org/-/work_items/22739 (~"group::operate" can assist on demand; but context wise these epics are a better fit). _Copied from https://gitlab.com/groups/gitlab-com/gl-infra/software-delivery/operate/-/epics/11#note_3697193160_ <!-- STATUS NOTE END -->
epic