# App-Delivery Object Mapping

Date: 2026-03-28

## Purpose

This document supplements `service-deployment-topology.md` by mapping `app-delivery` deployment objects to source repositories or source families.

The goal is not to force false precision.
When current KB evidence is not enough for a single exact repo, this document records:

- the most likely repo family
- the confidence level
- why the confidence is not higher

## Mapping Classes

### Class A: Direct Mapping to a Scanned Source Repo

These objects map cleanly to a repo already represented in `knowledge/repos/`.

| Deployment object | Source repo | Confidence | Rationale |
| --- | --- | --- | --- |
| `auditservice` | `tidbcloud/auditservice` | High | exact repo name and matching binaries |
| `authserver` | `tidbcloud/auth-server` | High | exact binary domain with matching interfaces |
| `account-svc` | `tidbcloud/account` | High | account repo exposes central/provider/worker binaries serving this domain |
| `billing-svc` | `tidbcloud/billing` | High | exact service domain |
| `config-center` | `tidbcloud/config-center` | High | exact repo and binary |
| `config-center-regional` | `tidbcloud/config-center` | High | `config-center` mapping directly references `config-center-regional` |
| `config-service` | `tidbcloud/config-service` | High | exact repo and binary |
| `core-svc` | `tidbcloud/core-svc` | High | exact repo and server binaries |
| `dataapps` | `tidbcloud/dataapps` | High | exact repo name |
| `dataflow-service-ng` | `tidbcloud/dataflow-service` | High | repo contains `dataflow-ng` binary |
| `metrics-integration` | `tidbcloud/metrics-integration` | High | exact repo and matching binaries |
| `serverless-metering` | `tidbcloud/serverless-metering` | High | exact repo and binary |
| `cost-metering-service-svc` | `tidbcloud/cost-metering-service` | High | exact repo exists in KB, and manifests use image `cost-metering-service` |
| `ipip-svc` | `tidbcloud/devtier-store-service` | High | `devtier-store-service` deep scan contains `ipip` binary, and both local `cd.yaml` and `app-delivery/ipip-svc` use the same `tidbcloud/ipip` image and command |
| `devops-service` | `tidbcloud/devops` | High | repo contains `devops-server` binary |
| `tcidm-service` | `tidbcloud/tcidm` | High | exact regional service binary |
| `cluster-ng-service` | `tidbcloud/cluster-service-ng` | High | repo contains `cluster_ng_server` |
| `gke-provider` | `tidbcloud/gke-provider` | High | exact repo name exists in KB |
| `novu-svc` | `tidbcloud/novu` | Medium | exact domain repo exists, but KB classifies it as deployment config rather than service code |

## Class B: Mapped to a Multi-Binary Source Family

These objects clearly belong to one repo family, but the deployment object name is not the exact repo name.

### `tidb-management-service` family

| Deployment object | Source family | Confidence | Rationale |
| --- | --- | --- | --- |
| `tidb-mgmt-service` | `tidbcloud/tidb-management-service` | High | exact binary in repo |
| `dedicated-global-service` | `tidbcloud/tidb-management-service` | High | exact binary in repo |
| `nextgen-global-service` | `tidbcloud/tidb-management-service` | High | exact binary in repo |
| `serverless-global-service` | `tidbcloud/tidb-management-service` | High | exact binary in repo |
| `serverless-global-regional-proxy` | `tidbcloud/tidb-management-service` | Medium | closest source binary is `regional_proxy`; deployment name differs |
| `tempo-migrate` | `tidbcloud/tidb-management-service` | High | manifests run `/command/tempo-migrate/tempo-migrate` from the `tidb-management-service` image, and `service-catalog` classifies `tempo-migrate-service` under `tidb-management-service` |
| `tempo-proxy` | `tidbcloud/tidb-management-service` | High | exact binary in repo |
| `tempo-wrapper` | `tidbcloud/tidb-management-service` | High | exact binary in repo |
| `tidb-mgmt-portal` | `tidbcloud/tidb-management-service` | High | exact binary in repo |
| `dedicated-3-layer-migrate` | `tidbcloud/tidb-management-service` migration family | Medium-High | the package deploys `dedicated-tempo-migrate` jobs and config points to `tempo-migrate-service.tidb-management-service`, so this is a dedicated migration unit in the same service family |

### `dataflow-service` family

| Deployment object | Source family | Confidence | Rationale |
| --- | --- | --- | --- |
| `dataflow-svc` | `tidbcloud/dataflow-service` | High | repo contains `cmd/dataflow` |
| `dedicated-ticdc-service` | `tidbcloud/dataflow-service` | Medium | service mappings reference `regional-ticdc-service`; deployment package name differs |

### `dataservices` family

| Deployment object | Source family | Confidence | Rationale |
| --- | --- | --- | --- |
| `dataservice-central-svc` | `tidbcloud/dataservices` | Medium | repo exposes central-style binaries and central service mappings |
| `dataservice-regional-svc` | `tidbcloud/dataservices` | Medium | repo exposes regional gateway/executor binaries; deployment name is package-level |

### `metering` family

| Deployment object | Source family | Confidence | Rationale |
| --- | --- | --- | --- |
| `dedicated-metering-server` | `tidbcloud/metering` | High | the package deploys `instance-metering-server` and `network-metering-server`, while the `metering` repo exposes `instancemetering`, `networkmetering`, and related metering binaries in the same family |

### `infra-provider` family

| Deployment object | Source family | Confidence | Rationale |
| --- | --- | --- | --- |
| `dedicated-regional-server` | `tidbcloud/infra-provider` | High | repo contains `regional-server` binary |
| `infra-exporter` | `tidbcloud/infra-provider` | High | exact binary in repo |
| `infra-webhook` | `tidbcloud/infra-provider` | High | exact binary in repo |
| `quota-exporter` | `tidbcloud/infra-provider` | High | exact binary in repo |
| `eks-provider` | `tidbcloud/eks-provider` | Medium-High | release metadata points to `https://github.com/tidbcloud/eks-provider/blob/main/Dockerfile`, manifests use image `tidbcloud/eks-provider`, and multiple repos still import `github.com/tidbcloud/eks-provider` or `github.com/tidbcloud/eks-provider/api`; KB is missing the repo entry, but the repo identity itself is clear |
| `gardener-provider` | `tidbcloud/infra-provider` family | Medium | deployment uses image `dbaas/infra-api/infra-provider`, so current evidence points to infra control-plane/provider code rather than a standalone scanned repo |
| `chaos-provider` | `tidbcloud/infra-provider` | Medium | repo contains `chaos-provider` binary, but role is admin/tool-like in scan result |
| `cluster-service` | `tidbcloud/infra-provider` | Medium | service mapping contains `cluster-server.json`; deployment name differs |
| `config-manager` | `tidbcloud/infra-provider` | Medium-High | `infra-provider` deep scan exposes `config-manager/cmd/server` with the deployed metrics, probes, webhook, and cluster-config reconciliation surface, which matches the app-delivery package more closely than the legacy `infra-api` `cmd/config-manager` entrypoint |
| `dedicated-region-base-services` | `tidbcloud/infra-provider` family | Low | likely a deployment bundle around regional platform services, not one source binary |
| `tidb-worker` | `tidbcloud/aws-shared-provider` | High | `aws-shared-provider` deep scan contains `cmd/tidb-worker`, and manifests use image `aws-shared-provider-tidb-worker` |

### `observability` family

| Deployment object | Source family | Confidence | Rationale |
| --- | --- | --- | --- |
| `o11y-agent-control-server` | `tidbcloud/observability` | High | repo contains `agent-control-server` binary |
| `o11y-svc` | `tidbcloud/observability` | Medium | same domain family, but deployment name is broader than any one binary |
| `o11y-cluster-agent-crd` | `tidbcloud/observability` addon/CRD package | Medium | CRD group is `agent.observability.pingcap.com`, which clearly aligns with the observability domain, but the deployment object is packaging rather than one executable |

### `serverless-service` family

| Deployment object | Source family | Confidence | Rationale |
| --- | --- | --- | --- |
| `serverless-regional-service` | `tidbcloud/serverless-service` | Medium | repo exposes the serverless runtime surface, but deployment name is region-specific packaging |
| `serverless-svc` | `tidbcloud/serverless-service` | High | manifests use image `serverless-service` and execute `/serverless-service` for grpc/http/worker variants |
| `serverless-meta-service` | `tidbcloud/serverless-metering` | High | manifests use image `serverless-metering` and execute `/serverless-metering meta-server`, which is a direct binary-level match |

### `aws-shared-provider` family

| Deployment object | Source family | Confidence | Rationale |
| --- | --- | --- | --- |
| `serverless-meta-store` | `tidbcloud/aws-shared-provider` | High | manifests use image `aws-shared-provider-meta-server`, and the repo scan contains `cmd/meta-server` |
| `serverless-ops-service` | `tidbcloud/aws-shared-provider` | High | manifests use image `aws-shared-provider-ops-service`, and the repo scan contains `cmd/ops-service` |
| `ng-autoscaler` | `tidbcloud/cluster-service-ng` dataplane-manager family | Medium-High | `cluster-service-ng` contains the `internal/dataplane-manager/helm/ng-autoscaler` chart, while manifests deploy image `tidbcloud/ng-autoscaler` into next-gen dataplane contexts |

## Class C: Infra API / Control-Plane Packaging Objects

These are deployment objects that are clearly part of the infra control plane, but are packaged at deployment level rather than repo level.

| Deployment object | Source family | Confidence | Rationale |
| --- | --- | --- | --- |
| `infra-api-crd` | `tidbcloud/infra-api` / `tidbcloud/infra-provider` | Medium | same API family; deployment object is CRD package |
| `infra-api-providerconfig` | `tidbcloud/infra-api` / `tidbcloud/infra-provider` | Medium | provider config packaging around infra API domain |
| `infra-api-webhook` | `tidbcloud/infra-api` / `tidbcloud/infra-provider` | Medium | webhook package in same control-plane family |
| `dedicated-infra-apiserver` | `infra-cd` apiserver stack + third-party Kubernetes control-plane bundle | High | app-delivery deploys `third-party/kube-apiserver` and `third-party/kube-controller-manager` images, while `infra-cd/projects/apiserver` owns the surrounding infra-apiserver stack and DNS/wiring |
| `infra-etcd-backup` | `infra-cd` apiserver stack operational backup bundle | High | app-delivery README defines it as the snapshot cronjob for the infra apiserver etcd cluster, and the manifest snapshots `https://etcd.infra.svc.cluster.local:2379` with third-party `etcdctl` plus `aws-cli` before uploading to the shared backup bucket |

## Class D: Platform Addons and Third-Party Bundles

These are deployed by `app-delivery`, but current KB does not suggest they should map to one TiDB Cloud business-service repo.

| Deployment object | Likely type | Confidence | Rationale |
| --- | --- | --- | --- |
| `external-secrets-operator` | third-party / addon bundle | High | deployment addon, not core business service |
| `cert-manager`-related regional objects | third-party / addon bundle | High | region addon package |
| `tiflow-crd` | CRD/addon bundle | High | deployment package, not business service repo |
| `vpa-agent` | addon / platform component | Medium | likely operator-side addon rather than first-party API service |
| `cluster-secret-store` | deployment bundle | Medium | package-level deployment concern, not enough source evidence |
| `dummy-http` | utility or test deployment | Medium | no clear business-service repo match |
| `lake-svc` | private endpoint connectivity proxy bundle | High | manifests are only `ExternalName` services (`lake-svc-proxy`) pointing at AWS VPCE hostnames, so the package is a private-endpoint connectivity shim rather than a workload built from a first-party source repo |

## Class E: Direct Additional Matches Outside the First Three Documents

These are useful small mappings that were not central enough for the topology doc but still have reasonable evidence.

| Deployment object | Source repo/family | Confidence | Rationale |
| --- | --- | --- | --- |
| `serverless-credits-campaign-svc` | `tidbcloud/serverless-credits-campaign` | Medium | same domain repo exists locally and in KB |
| `clusterproxy`-related usage under other objects | `tidbcloud/clusterproxy` | High | exact repo and proxy binary exist |
| `rbac-management-service` | `tidbcloud/account` | High | `account/tools/rbac-management/rbac_management.py`, `.pingcap/Dockerfile_rbac_tools`, and the `dev/staging/prod` `update-rbac` workflows together define and build the `dbaas/{env}/rbac-management` image later consumed by `app-delivery` |

## Class F: Deployment Bundles Spanning Multiple Services

These objects should not be force-mapped to one repo.
The package itself is the useful unit because it bundles several services, addons, or delivery concerns together.

| Deployment object | Likely source family | Confidence | Rationale |
| --- | --- | --- | --- |
| `clinic` | `tidbcloud/clinic-cd` multi-application delivery family | Medium-High | the only matching repo metadata is `clinic-cd`, and the delivery package bundles `clinic-api`, `clinic-data-service`, `clinic-ui`, `chaos-api`, `cloud-server`, `ngm`, Grafana, and addon pieces rather than one source binary |
| `nextgen-regional-control-plane` | next-gen regional platform bundle | High | package contains `dataplane-manager`, `o11y-agent`, `ticdc-service`, `crossplane`, `cert-manager`-adjacent components, and other regional control-plane pieces from multiple source families |

## Residual Ambiguity

The first-pass unresolved set is now fully resolved to repo, bundle, or control-plane family level for the current covered objects.
The remaining work is mostly bundle decomposition and deeper evidence collection inside broad delivery families, rather than ownership unknowns.

## Practical Usage Rules

When mapping an `app-delivery` object, use this precedence:

1. exact source repo and exact binary match
2. exact repo family with deployment-package renaming
3. infra/control-plane packaging family
4. addon / third-party deployment bundle
5. unresolved

Do not overfit a deployment object to one repo when the current KB only proves a family-level relationship.

## Suggested Follow-Up

1. Keep still-unscanned provider repos aligned with KB metadata so bundle-level mappings can be upgraded when deeper evidence appears.
2. Decompose broad multi-service delivery families further when the KB later contains source repos for their internal components.
3. Keep the machine-readable mapping projection updated so downstream graph tooling can consume the latest ownership decisions directly.