Klaudia <> GitHub Integration

Overview

Klaudia is Komodor's AI SRE agent. The GitHub integration lets Klaudia connect an investigation to the source of truth for your workloads: the manifests, configuration files, and application code in your Git repositories. When Klaudia diagnoses an issue that traces back to something in source control, it can locate the exact file and propose a fix as a pull request, so the correction lands permanently in Git rather than only as a live cluster change.

The integration is built on the Komodor GitHub App. Once repositories are connected, Klaudia can search them during an investigation and open remediation PRs against them, always with a human reviewing and merging the change.

Note:

• Komodor AI SRE agent ('Klaudia') uses a large language model (LLM) to generate responses. LLMs have the potential to produce inaccurate responses. Always review a proposed pull request before merging it.
• Klaudia never merges a pull request on its own. Every PR it opens is a proposal that follows your normal review and approval process.

How it works

1. Connect your repositories to the Komodor GitHub App (steps below). These include the repositories that hold your Kubernetes manifests, Helm values, and GitOps configuration, and, where you want Klaudia to reach application-level fixes, your application source code repositories.
2. Klaudia investigates an issue as usual, from the Komodor UI, from Slack, or triggered automatically.
3. Klaudia identifies where the root cause lives. The fix may sit in a configuration value in source control (for example a memory limit or a replica count) or, when Klaudia has access to the relevant applicative repository, in the application code itself.
4. Klaudia locates the source file by searching your connected repositories, using GitOps metadata and the distinctive values from the failing resource to find the right file and path.
5. Klaudia proposes a pull request with the suggested change, a description of the root cause, and the reasoning behind the fix.
6. You review and merge. The PR enters your normal review flow. Klaudia's role ends at the proposal.

What Klaudia can do with GitHub

When Klaudia opens a pull request (and when it does not)

Klaudia is deliberately conservative about opening PRs. A pull request is only proposed when the fix belongs in source control.

Klaudia will propose a PR for config-driven issues, such as:

• Resource limits and requests (for example raising a memory limit or lowering a CPU request)
• Replica counts and topology (for example a single-replica deployment that should scale, or topology spread constraints)
• Node group and IaC settings (for example increasing a node group max size)
• Application configuration held in manifests (for example Kafka settings, Spring Boot properties, or a regex pattern)
• Image tags (for example a stale tag or a version mismatch)
• Probe settings (for example startup probe timing)
• Other manifest fields (for example backoffLimit or namespace specs)

Klaudia will also propose a PR for application code issues when she has access to the relevant applicative repository and the root cause is in the code itself. In these cases Klaudia locates the responsible code and proposes the change directly in the application repository, with the root cause and reasoning described in the PR.

Klaudia will not propose a PR for operational or infrastructure-driven issues, such as:

• Node failures, kubelet failures, or unreachable nodes
• Cloud-managed operations (for example EKS node group AMI upgrades or ASG lifecycle terminations)
• Transient operational events (for example stuck finalizers, false alarms, or successful rollouts)
• Healthy resources where no action is needed

For these cases, Klaudia focuses on the immediate operational guidance (for example a kubectl-based fix) rather than a source change. When an issue has both an immediate operational fix and an underlying fragile configuration or code path, Klaudia aims to surface the operational fix and, where the source lives in a connected repo, propose the permanent fix as a PR.

How Klaudia finds the right file

To open an accurate PR, Klaudia has to map a live Kubernetes resource, or an application behavior, back to the file that defines it. It does this by combining GitOps metadata with the actual values from the failing resource:

• GitOps labels first. Where ArgoCD, Flux, or Helm labels are present on the resource, they point Klaudia directly to the owning repository and path. This is the most reliable signal and produces the best results.
• Distinctive values. Klaudia searches for the specific current value in the source (for example image: <tag> or memory: 32Gi) rather than a generic resource name, because distinctive values resolve to a unique file.
• Repository scope. Only repositories connected to the Komodor GitHub App are searchable. If the relevant repo is not connected, Klaudia cannot locate the file and will let you know rather than guessing.

Tip for best results: connect the repositories that hold your workload manifests, GitOps configuration, and (where you want application-level fixes) your application code, and keep GitOps labels intact on your resources. Both materially improve the accuracy of PR proposals.

Prerequisites

• A Komodor account with the GitHub integration installed.
• The repositories you want Klaudia to work with connected to the Komodor GitHub App. This includes your Kubernetes manifest and GitOps repositories, and any application code repositories where you want Klaudia to be able to propose code fixes.

The Komodor GitHub App

The integration runs through the Komodor GitHub App. When you install it, the app requests the following permissions:

Permissions

• Read access to metadata
• Read and write access to code and pull requests

These permissions let Klaudia read the repositories you connect, search them to locate the source of an issue, and open pull requests with proposed fixes. Klaudia can open pull requests but cannot merge them. Merging stays a human action, governed by your repository's branch protection and review rules.

Installation and connecting repositories

1. In the Komodor platform, go to Integrations.

2. Locate GitHub under Available Integrations and click Install Integration. 

   

3. Authorize the Komodor GitHub App in GitHub. Choose the organization and select whether to grant access to all repositories or specific ones. 
   
   
    
4. Review and approve the requested permissions (metadata read; code and pull requests read and write). 

5. Once completed, GitHub appears under Installed Integrations, and connected repositories become searchable by Klaudia. 

   

Permission model

• Klaudia's actions are scoped to the invoking user's Komodor RBAC. Data the user is not authorized to see in Komodor is not surfaced.
• The Komodor GitHub App operates within the repository permissions granted at install time. Klaudia can open pull requests but cannot merge them; merge remains a human action under your repository's branch protection and review rules.

Audit log

Klaudia's GitHub actions are recorded in the Komodor audit log, including:

• Action taken (for example "proposed pull request")
• The user whose investigation triggered the action
• Timestamp
• Target repository and pull request reference
• Triggered by: Klaudia or User

FAQ

Will Klaudia merge changes to my repositories? No. Klaudia only proposes pull requests. Merging is always a human action and follows your existing review and branch protection rules.

Can Klaudia change my application code, not just my manifests? Yes. When Klaudia has access to the relevant application code repository and the root cause is in the code itself, she can propose a fix directly in that repository as a pull request. If the applicative repository is not connected, Klaudia cannot reach the code and will focus on the fixes available to her.

Why didn't Klaudia open a PR for my incident? Most likely because the root cause was operational or infrastructure-driven rather than something in source control, in which case a PR is not the right fix. It can also happen when the relevant repository is not connected to the GitHub App, or when the source file could not be located.

Which repositories should I connect? Connect the repositories that hold your Kubernetes manifests, Helm values, and GitOps configuration, plus any application code repositories where you want Klaudia to be able to propose code fixes. Klaudia can only search and open PRs against connected repositories.

Does the integration work with GitOps tools like ArgoCD and Flux? Yes. When ArgoCD, Flux, or Helm labels are present on a resource, Klaudia uses them to find the owning repository and path, which produces the most accurate PR proposals.

Do you support more than one GitHub organization? Yes. Multi-org GitHub is supported.