Understanding the Managed Data Plane

The managed data plane is the opt-in tier of Tetrate Patch Service where Tetrate goes beyond observing what runs in your clusters and owns the desired state itself. This page explains the repository model, the file split that keeps your configuration safe through upgrades, and the path an upgrade takes from a pull request to images observed running. Git is the only channel between Tetrate and your cluster, and nothing changes until your organization approves it.

What Is the Managed Data Plane?

Every Patch Service customer runs the agent, which reports what is actually running. The managed data plane goes one step further: Tetrate also owns your desired state, kept in a private GitOps repository on GitHub created for your organization alone. ArgoCD runs in your cluster and continuously reconciles that repository into it, with automated sync, pruning, and self-healing.

The consequence is worth stating plainly: what is on main is what runs. If someone edits a managed workload directly in the cluster, self-healing reverts the change on the next sync, so the repository is always the authoritative description of your data plane. To change what runs, change the repository.

The tier is opt-in, chosen when Tetrate provisions your organization. Every user in your organization gets read access to the repository automatically, and My Repo appears in the sidebar to open it directly. Read access is the whole grant, so every change, Tetrate's upgrades included, arrives as a pull request that waits for your approval.

Products and Environments

Your repository holds one top-level directory per product, for example teg. Each product deploys to one or more named environments under it: you choose the names, such as dev and prod, and a product that runs in a single environment uses default. Both halves of the upgrade contract repeat at the product level and inside each environment, so a version can be staged one environment at a time.

teg/            product defaults shared by every environment
teg/envs/dev/   overrides for the dev environment
teg/envs/prod/  overrides for the prod environment
agent/          reserved for the cluster agent

The agent directory is reserved. The agent is not a product: it is installed once per cluster and shared by every product running there, so it lives in its own directory with the same layout. Agent upgrades arrive as pull requests like everything else, on their own cadence, and the agent's configuration is entirely Tetrate-managed, with no customer layer.

The Upgrade Contract

The contract between Tetrate and you is a file split, repeated at every layer of the repository.

File kind	Who edits it	What it holds
Version files	Tetrate, through pull requests	The chart revision and every container image the chart deploys, each pinned separately
Customer files	You	Resource requests, node affinities, gateway placement, and similar customization

Tetrate never touches customer files, and you never edit version files by hand. The split is what makes automated upgrades safe: a change touching only version files can never clobber your configuration.

Pinning every image separately matters too. A chart revision bump changes chart templates only, never an image version as a side effect, so each component moves exactly when its own entry moves.

How an Upgrade Reaches Your Cluster

A scheduled job inside your own repository compares every pinned image against Tetrate's release catalog daily and opens an upgrade pull request when one falls behind its latest release. It opens one pull request per layer: product defaults in one, each environment in its own, so releasing dev first and prod only after you have watched it is the natural motion rather than a workaround. The job opens pull requests, never commits. It keeps at most one open pull request per layer, updates it in place when a newer release lands, and closes it automatically if a manual bump made it unnecessary. The same catalog comparison drives the orange Upgrade available markers in the Clusters view, so the console and the pull requests draw on one source.

From the approval onward, the loop closes without any connection between Tetrate and your cluster. You release the request, ArgoCD rolls the new images out, and the agent's next snapshot reports them running. That report is the proof, and the replaced image's findings resolve at the next scan. An upgrade is only done when the new images are observed running. The console shows what the agent last reported, so a merged upgrade that has not rolled out yet still shows the old version: evidence, not assumption.

Releasing a Change

Because your accounts hold read access, the release signal is a comment rather than GitHub's review button, which only counts approvals from accounts that could merge the change themselves. Commenting /approve on a pull request is what releases it, and the automation seeded in your repository performs the merge.

Three checks on each request say where it stands: your approval, whether anyone has asked to /hold it, and whether the change reaches beyond the files you own and therefore needs a Tetrate review as well. An automated version bump touches only a version file, so your approval is the only thing it waits for. An approval binds to the commit it was given on, so a newer release landing on an open request asks for it again.

Approving Changes has the commands, the checks, and the setting that decides whether approving also merges.

Security Model

The tier is designed so that managing your data plane never requires handing Tetrate access to it:

• Tetrate holds no credentials to your cluster. Git is the only channel between Tetrate and your data plane, and the moment your cluster changes is the moment you release a pull request.
• The deploy key ArgoCD uses to pull the repository is read-only. A compromised cluster can read its own desired state but can never push, so it cannot poison its own future syncs.
• The upgrade job runs with your repository's own credentials. No Tetrate credential is involved anywhere in the loop, so there is none to leak.
• The approval gate reads its rules from the default branch, never from the pull request being judged, so a request can never widen what it is allowed to change.

Next Steps

• Read Working with Your Repository when you want to adjust resource requests, affinities, or gateway placement through your customer files.
• Read Receiving Managed Upgrades before your first upgrade pull request arrives, so you know what to review and what releasing it sets in motion.
• Read Approving Changes for the commands that release a change and the three checks that gate it.
• Read Clusters and the Agent to understand the observation side, where snapshots prove what your clusters actually run.