Yamlr is a Kubernetes manifest auditing and healing engine. While standard tools validate individual resource structures against OpenAPI schemas, Yamlr analyze the logical integrity of the entire system.
Schema errors are caught by standard validators; however, logical misconfigurations—such as broken service selectors or dangling secret references—often remain silent until deployment. Yamlr identifies these cross-resource failures locally and deterministically.
1. The ResourceGraph (Dependency Mapping)
Kubernetes resources are intrinsically linked. Yamlr constructs a directed dependency model called the ResourceGraph.
This graph currently maps 25+ distinct relationship types across your manifests:
- Service → Pod: Validates that service selectors resolve to active Pod labels. (Prevents Ghost Services).
- Ingress → Service: Ensures the backend Service exists and the target port is defined.
- ConfigMap/Secret → Pod: Verifies that required environment variables and volume mounts exist and are populated.
- HPA → Deployment: Ensures the scale target reference is valid.
- NetworkPolicy → Pod: Maps isolation boundaries and traffic flow.
- PDB → Pod: Validates disruption budgets against replica counts.
This cross-resource awareness enables blast radius analysis — allowing the engine to know exactly which dependent resources will break if a foundational resource is misconfigured.
2. Risk Classification Layer
Every finding is processed by a Risk Classifier which uses heuristic scoring to categorize findings into Safety Domains based on their impact.
The engine assigns a deterministic risk level (HIGH, MEDIUM, LOW) by evaluating the context of the failure:
- Traffic Routing Failure: E.g., An Ingress pointing to a dead port.
- Data Dependency Failure: E.g., A Pod mounting a Secret that doesn't exist.
- Security Policy Violation: E.g., Running a container as root without a dropping capabilities.
- API Deprecation Risk: E.g., Using
v1beta1for CronJobs on a 1.28 cluster.
Each category calculates an impact scope (cluster vs namespace) and assigns a deterministic risk level (HIGH, MEDIUM, LOW).
3. Semantic DNA Integrity
To ensure that Yamlr never breaks a customer's production cluster during an automated repair, every manifest is protected by Semantic DNA.
Yamlr computes a cryptographic hash of the semantic meaning of your manifest. If the Healing Engine runs an automated repair, it recalculates the DNA. If the repair accidentally altered the fundamental meaning of the resource beyond the intended fix, Yamlr aborts the write.
This guarantees zero accidental production drift.
4. Non-Destructive Code Formatting
Platform engineering teams spend thousands of hours formatting their IaC.
When Yamlr heals a file, it uses a proprietary non-destructive AST (Abstract Syntax Tree) engine to preserve:
- Quote styles
- Field ordering
- Whitespace alignment
- Existing
# comments
The resulting output is perfectly clean and GitOps-friendly. You get the fix without your git diff lighting up with whitespace changes.
5. Automatic Backup Rotation
Before Yamlr modifies any file on your disk, it creates a timestamped state snapshot.
- Snapshots are stored locally in
.yamlr/backups/. - The last 5 versions are strictly retained.
- Instant rollback is available command:
yamlr restore <path>.
Yamlr is designed for environments where failure is not an option.