# Architecture Decision Record: Helm and Kustomize Handling

Name: Taha Hawa

Initial Date: 2025-04-15

Last Updated Date: 2025-04-15

## Status

Proposed

## Context

We need to find a way to handle Helm charts and deploy them to a Kubernetes cluster. Helm has a lot of extra functionality that we may or may not need. Kustomize handles Helm charts by inflating them and applying them as vanilla Kubernetes yaml. How should Harmony handle it?

## Decision

In order to move quickly and efficiently, Harmony should handle Helm charts similarly to how Kustomize does: invoke Helm to inflate/render the charts with the needed inputs, and deploy the rendered artifacts to Kubernetes as if it were vanilla manifests.

## Rationale


## Consequences

Pros:
- Much easier (and faster) than implementing all of Helm's featureset
- Re-use code from K8sResource already present in Harmony
- Harmony retains more control over how the deployment goes after rendering (i.e. can act like Kustomize, or leverage Kustomize itself to modify deployments after rendering/inflation)
- Reduce (unstable) surface of dealing with Helm binary

Cons:
- Lose some Helm functionality
- Potential lose some compatibility with Helm

## Alternatives considered

- Implement Helm fully
    - Pros:
        - Retain full compatibility with Helm as a tool
        - Retain full functionality of Helm
    - Cons:
        - Longer dev time
        - More complex integration
        - Dealing with larger (unstable) surface of Helm as a binary
- Leverage Kustomize to deal with Helm charts
    - Pros:
        - 
    - Cons:
        -

## Additional Notes