traefik-helm-chart: Deploying Traefik Proxy on Kubernetes

What traefik-helm-chart Deploys on Kubernetes

traefik-helm-chart solves the deployment problem for Traefik Proxy, an HTTP reverse proxy and load balancer designed for routing traffic to microservices. Its audience is Kubernetes operators who want to install an ingress controller through Helm and configure it through chart values rather than maintain a collection of manifests manually.

The chart deliberately stays focused on Traefik deployment configuration. The project documentation says it avoids integrating third-party solutions or targeting specific use cases. That boundary matters when choosing an ingress chart. A team may expect an ingress chart to include a certificate workflow, external DNS integration, a service mesh hook, or vendor-specific storage preparation. This repository does not document those as built-in chart features. The intended extension points are ordinary Helm values, separately applied Kubernetes configuration, `extraObjects`, or inclusion as a Helm subchart.

Starting with chart version v28.x, the chart bootstraps Traefik Proxy version 3 as a Kubernetes ingress controller based on the `IngressRoute` custom resource. This is a major platform boundary. The repository links separate migration documentation for chart upgrades from versions that used Traefik Proxy version 2, and it warns that a new chart major version can contain an incompatible breaking change. Existing users should therefore treat the chart version and the proxy version as separate compatibility decisions.

IngressRoute, Gateway API, and CRD Boundaries

The chart's Kubernetes integration is primarily built around the `IngressRoute` custom resource. This means the deployment is not merely a container image with a Service and Ingress. The cluster also needs the CRDs that Traefik uses to express its routing model. The chart previously shipped with a dedicated `traefik-crds` arrangement, but the README says that approach was deprecated in v38.0.2.

Gateway API support has another explicit boundary. The README states that Gateway API CRDs are no longer included in this chart. If the Kubernetes Gateway API provider is selected, an administrator must install the Gateway API CRDs before deploying Traefik v3.7.12. This gives the chart a smaller default scope, but it also moves responsibility for CRD lifecycle and version coordination to the deployment process.

There is a version detail worth checking before copying commands between documentation sections. The installation section points to Gateway API `v1.6.1`, while the upgrade sequence points to `v1.5.1`. The README does not explain that difference. That inconsistency should be resolved against the Gateway API version required by the selected Traefik Proxy release rather than treating either URL as universally interchangeable.

The chart also does not update CRDs automatically when Helm's native CRD management is used. The README calls this a Helm caveat and marks CRD upgrading as a mandatory step before `helm upgrade`. This is operationally significant: a routine Helm update can be incomplete unless the operator separately retrieves and applies the chart's CRDs.

Installing traefik-helm-chart with Helm 3

The documented prerequisites are Kubernetes server v1.30.0 or higher and Helm v3.9.0 or higher. Check the local Kubernetes client and Helm installation with the commands documented by the project:

kubectl version
helm version

The chart repository must then be added before installing from the GitHub Pages Helm repository:

helm repo add traefik https://traefik.github.io/charts

A default deployment is created with this command:

helm install traefik traefik/traefik

The README also supports installation through the OCI registry. This uses the same release name and chart coordinates, but Helm retrieves the chart from the OCI registry:

helm install traefik oci://ghcr.io/traefik/helm/traefik

That command is written in the README as `helm install traefik oci://ghcr.io/traefik/helm/traefik`. The release will not by itself demonstrate ingress behavior. A first real check should confirm that the release exists and inspect its Kubernetes resources and events. The README does not document a single smoke-test URL or a mandatory test workload, so the exact post-install checks depend on the cluster and the services being routed.

A Values-Based First Customization

The chart's preferred customization surface is a Helm values file. The README points to `EXAMPLES.md` for common configurations and `traefik/values.yaml` for all available parameters. That separation is useful because it keeps the deployment intent outside the chart source, allowing environment-specific settings to be reviewed and versioned independently.

Create a file such as `myvalues.yaml`, add only the settings required by the environment, and pass it after the install subcommand. The syntax is documented as follows:

helm install -f myvalues.yaml traefik traefik/traefik

Helm combines this file with the chart defaults. The repository does not provide a complete `myvalues.yaml` example here, so inventing service types, ports, TLS settings, or resource limits would misrepresent the chart. Those values should be selected from `traefik/values.yaml` and the linked examples.

For configuration that is not represented as a chart value, the README gives a different route: prepare a Kubernetes manifest and apply it separately. It describes this as appending custom configuration, with `myconf.yaml` as the example input:

kubectl apply -f myconf.yaml

This separation can keep the upstream chart generic, but it also divides ownership. Helm users must know whether a change belongs in `values.yaml`, `extraObjects`, an external manifest, or a parent chart. The README does not document a precedence or validation rule for every possible external object, so those choices should be reviewed in the rendered release rather than assumed.

Provenance Verification for Chart Releases

Chart releases from v37.0.0 onward include provenance files. The README provides a concrete verification path for the official Traefik chart signing key. First, GnuPG retrieves the key from the documented key server:

gpg --receive-keys --keyserver hkps://keys.openpgp.org 'B0FBA7678F685E9B7024B79FFD92BB57C5A71A99'

GnuPG v2 does not store the keyring in a format Helm can use for provenance verification, according to the README. Export it in the legacy keyring format:

gpg --export --output $HOME/.gnupg/pubring.gpg 'B0FBA7678F685E9B7024B79FFD92BB57C5A71A99'

The fetch commands then request verification. For OCI, `<VERSION>` must be replaced with the release version being checked:

helm fetch --verify --keyring $HOME/.gnupg/traefik.pubring.gpg oci://ghcr.io/traefik/helm/traefik:<VERSION>

For the Helm repository, the documented form is:

helm fetch --verify --keyring $HOME/.gnupg/traefik.pubring.gpg traefik/traefik --version <VERSION>

There is a path discrepancy in the README. The export command writes `pubring.gpg`, while both fetch commands read `traefik.pubring.gpg`. As written, those examples do not reference the same file. An operator should either export to the path used by `helm fetch` or pass the actual exported path to `--keyring`; the README does not resolve this inconsistency.

Upgrading the Chart and Its Custom Resources

The upgrade procedure has more moving parts than a normal `helm upgrade`. The README says to read the release notes first because major chart versions may introduce incompatible changes. It also says that CRDs must be upgraded before the chart when Helm's native CRD management is in use, because Helm does not update them automatically.

The documented sequence updates the repository, checks the currently available chart, applies Traefik CRDs, updates Gateway API CRDs if needed, and then upgrades the release:

helm repo update
helm search repo traefik/traefik
helm show crds traefik/traefik | kubectl apply --server-side --force-conflicts -f -
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.1/standard-install.yaml
helm upgrade traefik traefik/traefik

The `helm search repo` line identifies the chart version available from the repository, but the README does not show a `--version` pin in the upgrade command. Production operators may therefore need to replace that command with an explicitly selected release version according to their release process. The repository warns against upgrades without reviewing chart notes, but it does not define a universal rollback command or a compatibility matrix for every intermediate chart release.

The `--server-side --force-conflicts` apply is explicitly part of the CRD procedure. That reduces manual conflict handling for the chart CRDs, but it also means the operator should inspect the rendered CRDs before using the pipeline. The README does not document a dry-run command or a rollback strategy for this step.

Maintenance, Licensing, and Chart Testing

The repository is not archived, and its last push was on 2026-10-15. Recent releases include v42.0.0 on 2026-10-15, v41.7.1 on 2026-10-09, and v41.7.0 on 2026-10-08. Based on the repository's archived and last-push facts, it is not abandoned, but its support policy follows the upstream Traefik Proxy release policy. A chart release does not by itself extend support for an unmaintained proxy version.

The project is licensed under Apache-2.0. That license governs use of the chart repository code and distributions. The README does not replace the LICENSE file or offer legal interpretation, so teams handling distribution, notices, or third-party dependencies still need to inspect those files directly.

The Makefile provides development and validation targets backed by containerized tools. `make lint` runs the chart-testing image through `hack/ct.sh`, while `make test` first generates snapshots and runs `./hack/test.sh`. Documentation can be generated with `make docs`, and schema generation is available through `make schema` after installing the required Helm schema plugin. These targets concern chart development and release validation. They do not validate a live Kubernetes cluster or replace an application-level routing test.

Editorial conclusion

Adopt this chart when a Kubernetes cluster already meets its version requirements and the team wants a generic, values-driven Traefik Proxy deployment with explicit CRD control. Do not adopt it if you need bundled third-party integrations, bundled Gateway API CRDs, or an automatic CRD upgrade path. Before the first release, verify the Kubernetes and Helm versions, choose a supported Traefik Proxy version, and inspect whether existing Gateway API CRDs already satisfy the provider requirements. For upgrades, the first concrete checkpoint is `helm show crds traefik/traefik` followed by the documented CRD apply step.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. traefik/traefik-helm-chart on GitHub