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