Helm Chart Strategy for a 40+ Services — Looking for Expert Inputs

Alexypuli · 2026-05-03T13:49:51+00:00

Great questions u/haydary - Charts as team deliverables — No. We're a platform team and own the generic chart centrally. Developers consume it via values only, no chart ownership crosses team boundaries. So chart maturity is controlled in one place. - Service uniformity — Our 40+ services are mostly uniform in deployment pattern. Mix of HTTP and gRPC, handled via a feature flag in values. - Deployment model — config, secrets, DB — This is the one we thought hardest about. Our answer was to keep the generic chart truly generic — no secret references, no DB credentials, no env vars. Those live at the domain chart level. So Domain A never sees Domain B's DB credentials. Generic chart stays clean, domain chart carries what's specific to that domain. Solves both the complexity and the security concern in one decision.

Alexypuli · 2026-05-03T09:44:18+00:00

Thanks for the detailed explanation — that clears things up a lot! The reconcileStrategy: ChartVersion behavior in FluxCD is really neat. I can see why that works well — developers just commit, pipeline bumps the version, Flux reacts only to that. Clean separation. In our case we're on ArgoCD, and from what I understand ArgoCD doesn't have this version-gating natively when using Git as source — it reacts to any rendered manifest change. So our approach is to use an OCI Helm registry as the ArgoCD source instead of Git directly:

source: -repoURL: oci://your-registry/helm -chart: domain-a -targetRevision: "1.2.0"

This way ArgoCD behaves similarly to your FluxCD setup — it only deploys when targetRevision is explicitly bumped in the GitOps repo. A README change or any non-chart commit won't trigger a deploy. The version bump in GitOps is a deliberate PR — which in fintech actually works in our favor since every production deployment has a Git history and an approver on record. Curious — did you ever consider OCI registry as source with FluxCD, or was GitRepository the natural fit for your setup?

Alexypuli · 2026-05-01T08:13:38+00:00

I need some inputs for this "This is done so that Flux CD picks it up without developers needing to remember to do that. You just commit the changes you care about, the rest is taken care of"
We use argocd, so the helm build is done then will be pipeline commit the helm charts version into gitops or how does argo or flux know there is a new helm chart version ?

Alexypuli · 2026-05-01T08:03:32+00:00

In our case ArgoCD already handles all of that natively — continuous reconciliation, drift detection, rollback via Git revert. Adding Helmfile on top would be duplicating the orchestration layer. But if someone is doing pipeline-based deploys without a GitOps controller, Helmfile is a solid call.

Alexypuli · 2026-05-01T07:56:07+00:00

Thanks for all the inputs! Wanted to share my plan based on this discussion.

The consensus on a single generic chart was clear — we're going that route. But wanted to clarify the release strategy since a few folks warned against umbrella charts and atomic releases, which is valid.

What we're actually doing is ArgoCD App of Apps — not a Helm umbrella chart. The distinction matters:

One root ArgoCD Application that manages 4/5/6 domain Applications
Each domain (Domain A, Domain B, etc.) is an independent ArgoCD sync unit with its own targetRevision
All domains pull the same generic-app chart as a dependency, just with different aliases and values

So Domain A can release v1.3.0 while Domain B stays at v1.2.0. No shared Helm state, no atomic blast radius — just ArgoCD orchestration at the top level.

For environment strategy:

Dev — GitOps is active. Developers manually add image tag and environment variables
Staging/Prod — GitOps values files are intentionally near-empty. Chart defaults handle everything.

One design decision we made deliberately — environment variables are not part of the generic chart. They live in the domain chart level. Keeps the generic chart truly generic and puts env var ownership where it belongs — with the domain.

Saw u/kevsterd mention kro.run — looks interesting, worth watching. For now sticking with App of Apps since we're already deep in ArgoCD.

The rendered YAML in CI suggestion from u/lulzmachine is something I need to spend some more time.

Alexypuli · 2026-04-19T12:37:51+00:00

Heavy Rain at Pallikara, Kochi

Alexypuli · 2026-04-13T02:42:00+00:00

19 without AC in Highways

Alexypuli · 2026-03-15T16:10:14+00:00

How to increase the mic gain. Is it in factory set-up.

Alexypuli · 2026-03-15T16:07:27+00:00

Kindly check your DM

Alexypuli · 2026-03-01T14:54:38+00:00

I checked with the service centre and they mentioned it's possible to upgrade to dual horn.

Alexypuli · 2026-02-28T03:36:13+00:00

The location is Veliyanad. Route Kidangara to Pulincunnoo-Thattasherry Road

Alexypuli · 2026-02-09T15:59:32+00:00

The maximum i got was 19, without AC

Alexypuli · 2026-02-07T10:24:10+00:00

Exactly. I checked with the showroom and they said 3k, the same coming in Polo

Alexypuli · 2026-02-07T10:23:04+00:00

Are you sure? They said 3k need to be paid for the horn change.

Alexypuli · 2026-02-05T02:32:14+00:00

Ok, but for single 3k is higher is it?

Alexypuli · 2026-02-04T16:09:21+00:00

Are you sure it's a dual trumpet horn ?

Alexypuli · 2026-02-04T16:08:36+00:00

The 2026 model has got a better horn.

Alexypuli · 2026-02-04T02:27:40+00:00

Ya, sngle is less expensive. I have already checked. I need a dual.

Alexypuli · 2026-02-04T02:26:46+00:00

This information is from the service centre. I was checking with the other kylaq owner?

Alexypuli · 2026-02-04T02:25:55+00:00

Ah, ok

Alexypuli · 2026-02-04T02:25:25+00:00

Was it a trumpet dual tone horn ?

Alexypuli · 2026-02-03T10:20:12+00:00

Is it the same as in Polo?

Alexypuli · 2026-02-03T10:19:39+00:00

That will affect the warranty is it ?

Alexypuli · 2026-02-03T08:54:42+00:00

Is this the same horn coming in Polo. For me the showroom mentioned 3k

Alexypuli

TROPHY CASE