Working with Your Repository

On the managed data plane, your data plane's desired state lives in a private GitOps repository on GitHub, seeded with the products your organization selected. It is the single channel between Tetrate and your clusters: what lands on main there is what ArgoCD runs, so working with your data plane means working with this repository. The model behind it is covered in Managed Data Plane; this page is about finding your way around it and changing it safely.

Finding Your Repository

Click My Repo in the sidebar to open the repository on GitHub. The link appears once Tetrate provisions your data plane, and every user in your organization gets read access automatically when Tetrate assigns them to your customer, so nobody needs a separate GitHub grant just to read the desired state.

Repository access

Access to the repository is read-only. Changes reach main only through a pull request someone released with a comment, which Approving Changes covers.

Repository Layout

The repository has one top-level directory per product, environments nested under each, and a reserved agent directory:

.github/                  the upgrade job, the review commands, and their settings
teg/                      product defaults shared by every environment
├── values-versions.yaml  version file: chart revision and image pins
├── values-customer.yaml  customer file: your customization
└── envs/
    ├── dev/              per-environment overrides, same file split
    └── prod/
agent/                    reserved: the cluster agent, Tetrate-managed

Two files repeat at every level, and the split between them is the contract. Version files (values-versions.yaml) are Tetrate-managed: the chart revision and every container image, each pinned separately, changed only through upgrade pull requests. Customer files (values-customer.yaml) are yours, and Tetrate never touches them.

The agent directory is reserved: the agent is installed once per cluster and shared by every product running there, so it is laid out like a product but is not one, and it has no customer layer to edit.

.github/ holds the automation itself: the scheduled job that opens upgrade pull requests, the workflow that acts on the commands you comment, and .github/upgrades.yaml, the one file there that is yours to change.

Customizing Your Data Plane

Your customization, resource requests, node affinities, gateway placement, lives in the customer files, and the path for changing them is the same as for any code you own:

1. Fork the repository. Your accounts have read access, so a fork is where your branch lives; a pull request from it is how the change gets here.
2. Edit the customer file at the level you mean: the product's file to affect every environment, an environment's file to affect just that one.
3. Open the pull request against main in your repository. Three checks appear on it, and the automation posts what it needs.
4. Comment /approve once your own review is done. A change confined to your own files merges on your word alone; one that reaches further waits for a Tetrate review too. The branch is deleted when the request merges.
5. ArgoCD applies the merge to the clusters running that product and environment on its next sync.

Git is the source of truth, so change Git

A change made directly in a cluster with kubectl is reverted by self-healing on the next sync. That is not an inconvenience to work around but the guarantee that makes the repository trustworthy: what you read in Git is what runs.

What You Can and Cannot Change

• Never hand-edit version files. Upgrades own them: the automated flow keeps at most one open pull request per layer and computes its diffs against the catalog, so a manual pin competes with the automation instead of instructing it. To hold an environment back deliberately, see freezing an environment.
• Customer files are entirely yours. Tetrate's pull requests touch version files only, so an upgrade can never clobber your customization.
• .github/upgrades.yaml is yours as well. It decides whether /approve also merges and by which method, and it is the one part of the automation you set.
• Everything else, charts, templates, and the rest of .github/, is Tetrate's. You can still propose a change to any of it; the request simply waits for a Tetrate review before it can merge.
• The deploy key your clusters use to pull the repository is read-only: nothing running in a cluster can push, so a compromised cluster cannot rewrite its own desired state.

Next Steps

• Approve changes for the commands that release a pull request here, and the checks they turn green.
• Receive managed upgrades to see what arrives in the version files you never edit by hand.
• Read Managed Data Plane for the model behind the repository: the file split, the security posture, and the evidence loop.
• Connect clusters to bring more of your fleet under the desired state this repository describes.