Load charts, merge values, and produce Kubernetes manifests from managed code. No helm binary. No Process.Start. No shell boundary in your application path.
You have a .NET application that needs the output of a Helm chart, but you do not want a runtime dependency on the helm executable. Maybe the caller is a web service, an operator, a build agent, or a product feature that needs to preview manifests before anything touches a cluster.
HelmSharp gives that code a managed path: load the chart, build values, render manifests, and optionally move into Kubernetes release operations.
var chart = await HelmChartLoader.LoadAsync("/charts/my-chart", ct);
var renderer = new HelmTemplateRenderer(chart, "demo", "default", values);
var manifests = renderer.Render();That is the core idea: chart in, manifests out, from your process.
Use HelmSharp.Action when you want a higher-level facade for template, install, upgrade, uninstall, rollback, status, package, repo, and registry-oriented operations.
using HelmSharp.Action;
var client = new HelmClient(optionsProvider);
var result = await client.TemplateAsync(new HelmTemplateRequest
{
ReleaseName = "demo",
Namespace = "default",
Chart = "/charts/my-chart",
SetValues = new Dictionary<string, string>
{
["image.tag"] = "1.2.3",
["replicaCount"] = "2"
}
});
Console.WriteLine(result.StandardOutput);The options provider is where an application centralizes defaults such as namespace, field manager, kubeconfig, and environment policy.
Most applications start with the high-level package:
dotnet add package HelmSharp.ActionUse narrower packages when your application only needs one layer:
dotnet add package HelmSharp.Chart
dotnet add package HelmSharp.EngineThe current golden suite renders 129/129 templates across podinfo, metrics-server, external-dns, ingress-nginx, and cert-manager without parser exceptions. That is the baseline HelmSharp uses to grow compatibility against real charts, not only hand-written fixtures.
HelmSharp already covers chart loading, values merging, managed template rendering, chart packaging, repository helpers, Kubernetes apply/delete/wait helpers, and release history backed by Kubernetes Secrets.
It is still an SDK with explicit compatibility boundaries. Some advanced Sprig behavior, output formatting details, OCI authentication flows, provenance verification, uncommon readiness cases, and plugin execution remain planned or active work. Check the compatibility page before depending on a specific Helm edge case.