JITSU-48: add prod mode (published images) to the Helm chart

[sahiltyagi-jitsu]

Implements JITSU-48 — one chart serving both self-hosted (prod / images) and dev (Minikube / source-build), selected by mode.

Stacked on #1517 (the chart rename), which is the base branch. Review that first; this PR retargets newjitsu automatically once it merges.

Requirements

Requirement	Status
mode value, dev | prod	✅ any other value calls fail
prod — published jitsucom/* images, no init-container compilation	✅ verified running, 11/11 pods
dev — build from mounted source in init containers	✅ byte-identical render
per-service image override wins regardless of mode	✅ verified separately in both
Ingress — external hostnames, TLS, console + ingest routing	✅ new template (there was no Ingress before)
prod covers sidecar + functions-server via images	✅ both follow image.tag

How it works

values.yaml gains mode, chart-wide image.{registry,tag,pullPolicy}, and empty per-service images.<service> blocks.

jitsu.image holds the whole precedence rule in one place:

1. images.<service>.repository — an explicit pin, honoured in both modes, so one service can run from an image while the rest build from source
2. prod — {{ image.registry }}/<name>:<tag>
3. dev — the base image the service builds against

Two mappings are passed explicitly rather than derived from the service name, because they are not one-to-one: profiles runs the rotor image with ROTOR_MODE=profiles, and the Go services run debian:bookworm-slim in dev because the golang image is their init container.

Image names were checked against .github/workflows/services.yaml rather than assumed — it publishes console rotor functions-server and bulker ingest sidecar syncctl operator ingmgr cfgkpr admin reprocessing-worker, so every service this chart deploys has a published image.

In prod the init containers, command overrides, hostPath/cache volumes and both hook Jobs are gated off. install-job exists only to populate the node-cache PVC from the host checkout. db-push-job is unnecessary because the console image migrates itself — its entrypoint runs prisma db push --skip-generate unless UPDATE_DB is disabled, which is exactly how the reference docker-compose deployment migrates (image, no command, no override). Keeping the job would mean two mechanisms racing on the same schema. Confirmed in the live run below.

Exposure

Prod forces every Service to ClusterIP — the four dev LoadBalancers would otherwise become four billed cloud load balancers with no TLS and no hostname. service.<name>.type overrides.

The Ingress is disabled by default and scoped to console + ingest, per the ticket and matching production (bulker is ClusterIP there; rotor is in no gateway config). Configurable class, annotations and TLS. Enabling it with no host fails the render rather than emitting an Ingress with no rules.

NEXTAUTH_URL and JITSU_PUBLIC_URL now derive from the Ingress host, scheme following ingress.tls.enabled. Without this a prod install behind an Ingress still advertised http://localhost:3000 — NextAuth would redirect users to their own machine after sign-in, and the tracking snippet would point browsers there.

Two things this refuses to do

Prod with the dev credentials. values.yaml ships JWT_SECRET: dev-jwt-secret-change-in-production and SEED_USER_PASSWORD: changeme so the Minikube quick start works. Nothing in Kubernetes flags them and the quick start gives a self-hoster no reason to look, so a prod render now fails and names the value to set.

An Ingress with no hosts. Renders nothing useful, so it fails instead.

Three bugs found by running it, not reading it

The chart could not be installed at all. Every service mounts jitsu-secrets via envFrom without optional: true, and that Secret was created by dev-deploy.sh — a dev bash script, not the chart. A fresh prod install failed with Error: secret "jitsu-secrets" not found → CreateContainerConfigError on all seven pods. This is precisely the ticket's complaint, "unusable for a real self-hosted install". The chart now creates it. Corrected after review: the first version rendered the Secret from a lookup of the existing one, which was wrong — lookup is empty during helm template, --dry-run and Argo CD repo-server rendering, so every reconciliation would have minted a new token and left pods disagreeing about the auth key. Replaced with a pre-install Job that creates the Secret in-cluster only when absent (see below).

helm-deps exposed the data layer publicly. All four datastores were type: LoadBalancer unconditionally, with no values switch. Harmless on Minikube (it is what minikube tunnel publishes); on any cloud provider it gives Postgres 5432, Kafka 9092, ClickHouse 8123/9000 and MongoDB 27017 public IPs, with the dev credentials the chart ships. Now defaults to ClusterIP, with dev-deploy.sh passing LoadBalancer explicitly. helm-deps/ is outside the directory JITSU-48 names, so flagging the scope call — it blocks the ticket's stated goal either way.

dev-deploy.sh deploy has been broken since 14 Sep — helm-deps timing out with context deadline exceeded after 10 minutes while every dependency pod is 1/1 Running (release revisions 3-6 all failed). Cause: helm's readiness check for a type: LoadBalancer Service requires status.loadBalancer.ingress, which Minikube only assigns while minikube tunnel is running — and deploy starts the project mount, not the tunnel. Confirmed: all four Services sit at EXTERNAL-IP <pending> with healthy pods and no tunnel process.

Not a regression — the LoadBalancer Services date from ee0d3a8b4 (7 Jul) and nothing in helm-deps changed since. The deploy only ever succeeded when someone happened to have a tunnel open. Fixed by waiting on the Deployments directly instead of on external IPs; ./dev-deploy.sh deploy now completes end to end (helm-deps revision 8 deployed, all 11 components ready).

This one is only in this PR because it is the same three lines of dev-deploy.sh the ClusterIP change touches. Easy to split out if you would rather it landed on its own.

The first two were invisible to helm template, which never resolves references to cluster objects. The third was invisible to it too — --wait is a client-side behaviour that rendering never exercises.

Verification

Dev is unchanged, checked at every step. Rendered output is identical to the pre-rename chart except one reworded comment inside a shell script. helm lint and kubectl apply --dry-run=server pass in both modes.

Prod mode runs. Two commands into an empty namespace — helm install jitsu-deps ./helm-deps and helm install ... --set mode=prod — reach 11/11 pods Ready on published images against real Postgres / Kafka / ClickHouse / MongoDB. No bash script, no source mount, no hostPath. Console migrated its own schema and initialised the ClickHouse events_log tables, then passed its healthcheck.

Prod render contains zero occurrences of hostPath, initContainers, /build/, node-cache, /cache/workspace, the golang/node/debian base images, and LoadBalancer.

Review round two — five findings, all fixed

jitsu-code-review raised five issues, and two of them meant prod mode did not actually work. Patterns for the fixes come from the community chart at stafftastic/jitsu-chart, which Ildar pointed at on the ticket.

Tokens regenerated on every reconciliation. Replaced the lookup with a pre-install Job that creates jitsu-secrets in-cluster only when absent, so rendering stays pure and upgrades never rotate. Its Role can create secrets and get only jitsu-secrets. auth.token still short-circuits the whole thing for external secret management.

A fresh prod install had no user — nobody could log in. The published console image only seeds when SEED_DEMO_CONFIGURATION is set, which also creates demo connections, so SEED_USER_EMAIL/SEED_USER_PASSWORD alone did nothing. Added a post-install Job calling manage.js seed directly; idempotent via the existing profileCount === 0 guard.

Credentials were readable from the pod spec. JWT_SECRET and SEED_USER_PASSWORD were passed with --set env.console.*, landing in the Deployment, in helm get values, and in shell history. The Job now mints both into the same Secret. A prod install needs no credential flags at all.

The operator managed the wrong namespace. KUBERNETES_NAMESPACE defaults to "default" (operator/config.go:27) and was never set, so a release installed elsewhere created functions-server Deployments in default. Now from the downward API, as syncctl already did. Not prod-only — dev-deploy.sh:12 takes NAMESPACE too, so this is a live bug in dev today, and it is the only dev-visible change in this round.

The console did not know the ingest endpoint. ingress.hosts.ingest made the host reachable but nothing told the console, so /api/app-config returned no ingest URL and the tracking UI advertised the wrong endpoint. Now derived from the same Ingress host.

Still verified

Dev renders identically apart from the operator namespace fix above. helm lint passes in both modes. Prod contains zero occurrences of changeme, dev-jwt-secret, hostPath, initContainers or /cache/workspace.

Also gone

jitsu.checkProdSecrets, which refused to render prod while the dev credentials were present. It existed only because values.yaml carried credentials that prod inherited; prod never sees them now, so it had nothing left to guard.

Acceptance — done, 3 of 3, on a real cluster

Run on the GKE Autopilot cluster from jitsu-cloud-infra#104, in prod mode, fresh namespace. Cold start ~2 minutes to all-running including a node scale-up — that is where the README's 5m number now comes from.

Fresh install, prod mode	token-generator hook Complete in 24s, all 11 keys written; seed Job Completed; 9/9 Running
Site → Destination → Function → Connection, event lands	rows in default.events carry an ac_marker column the function added — a field absent from what was POSTed, so ingest → Kafka → rotor → UDF → bulker → ClickHouse all ran. The schema-free path auto-created the column.
Service → Sync	syncctl created real pods mongodb--discover-4466 and mongodb-…-read-e7a5, both SUCCESS. 5 rows in default.customers, matching 5 documents seeded into the in-cluster MongoDB, types preserved. A scheduled sync also fired unprompted, so the cronjob controller works too.

The ticket's "prod mode must still cover sidecar/sync pods and functions-server via images" is proven by the same run: free-0-1-fs and both sync pods ran from published images.

Ingress — actually deployed this time

The first install ran --set mode=prod only, so the Ingress path had never been exercised — rendering it is not deploying it. Closed by installing ingress-nginx and using nip.io hostnames, so no DNS setup.

Routes both hosts	console and ingest on separate hostnames
Console URLs derived from ingress	NEXTAUTH_URL / JITSU_PUBLIC_URL / JITSU_INGEST_PUBLIC_URL, and they flip to https:// on their own when TLS is on
HTTP from the public internet	console + ingest 200
HTTPS from the public internet	both 200; HTTP 308-redirects to HTTPS
Certificate served	ours, not nginx's fake fallback — which is the failure mode the README warns about
Events over HTTP and HTTPS ingress	both landed in ClickHouse

Only the documented-correct TLS path (option a, existing TLS Secret) was exercised.

What running it as a client would produced

Six defects. None shows on Minikube, and two are invisible on Autopilot too, because it papers over them.

Fixed here:

1. redpanda fsGroup — 86ab2f47c. PVC arrives owned by root, image runs as uid 101.
2. --wait on the documented install — bbc5883c5. A bare helm install exited 0 while five services were in CrashLoopBackOff.
3. JWT_SECRET no longer shares the inter-service token — 9bf0705d7, P1 from review. In the auth.token path the console's session-signing secret was the same value handed to services as a bearer credential, so anyone holding one could forge an admin session. auth.jwtSecret is now separately required. Only ever affected the supplied-token path; the generated path already minted an independent secret, verified against the live install.
4. The token-generator's create grant stated accurately — 99955486f, P2 from review. Kubernetes cannot apply resourceNames to create, so that verb is namespace-wide whatever the Role says; pre-creating an empty Secret to avoid it would blank live keys on upgrade. Documented in the Role and README rather than silently accepted, and it corrects an overstatement in my own README table from 33ce48914.
5. Cluster rights and RBAC documented — 33ce48914. Prerequisites listed Minikube and Helm; the chart creates 8 RBAC objects, two cluster-scoped, and GKE's roles/editor excludes RBAC entirely. Now also documents the default-StorageClass requirement, and what each Role grants and why — including that pods/exec on syncctl is effectively shell access to pods in scope, and that both ClusterRoles span every namespace.

Found, not fixed — the scope call for you:

6. No resources anywhere, and no way to set them. Predicted in the previous version of this description; now confirmed and worse than expected — values.yaml has no resources key at all, so a client cannot set them without forking the chart. Every pod is BestEffort QoS, and a namespace with a LimitRange requiring requests rejects them outright. The same gap is in the sync pods syncctl generates. Autopilot hid it: the autopilot-default-resources-mutator lines in the install log are it patching this in real time.
7. helm-deps has no storageClassName override. Now documented as a requirement, but a client on a cluster whose default StorageClass is wrong for them still cannot choose another without forking.
8. Startup race. Services that read config from the console exit 1 rather than retrying (Cannot load cached repository. No CACHE_DIR is set.), four restarts each. Correction — this is not prod-specific. The commit message on bbc5883c5 says dev masks the race via its source-build init container. That is only true of a cold first install. Measured on Minikube afterwards: every dev-deploy.sh deploy replaces the console pod, and each dependent service then dies 4 times before it comes back — 48 restarts / 12 helm revisions = 4.0 per deploy, the same number measured in prod. The node had not rebooted, so upgrades are the whole mechanism. Dev developers have been hitting this on every deploy. CACHE_DIR is never set anywhere. The chart already has the fix pattern in seed-job.yaml (until wget … /api/healthcheck); adding it as an init container to those services would remove the crash-loop. Not done here because it touches five templates.

Plus one outside this chart: the ClickHouse destination form takes a hostname but silently accepts a URL. http://clickhouse parsed to host http; the only symptom was dial tcp: lookup http … no such host in bulker logs, nothing in the console.

Items 6–8 are the ones that matter most for self-hosting, since a client deploys onto a cluster we have never seen. Happy for any of them to become their own ticket.

Still open on the ticket

Two dev-mode checks this cluster cannot do, both needing Minikube: dev behaviour unchanged, and the behavioural check of the per-service image pin (render-level only so far).

Also outstanding, tracked separately: DX: verify the self-hosting quick-start end-to-end and fix drift.

🤖 Generated with Claude Code

[jitsu-code-review]

Reviewed the production Helm-mode templates, rendered dev/prod manifests, and traced the startup and public-endpoint paths. Findings: fresh prod installs do not bootstrap the configured admin, the configured ingest Ingress host is not passed to the console, and the operator still targets the default namespace.

[jitsu-code-review]

Reviewed the production Helm path, including rendered dev/prod manifests and the image entrypoints.

Findings:

• Production credentials supplied through env.console are rendered into the console Deployment and the Helm release record.
• Client-side/GitOps renders regenerate the default inter-service token because lookup has no live Secret to reuse.

[jitsu-code-review]

Reviewed the production Helm rendering, image/entrypoint paths, bootstrap flow, and deployment documentation. Findings: the documented fresh install omits dependency provisioning; auth.token leaves the seed password absent; seeding can race the console migration; and dev image pins still execute the locally built code.

[jitsu-code-review]

Reviewed the Helm production/dev rendering paths, bootstrap hooks, and service configuration.

Finding:

• The default prod token bootstrap hook is scheduled before the ServiceAccount and RBAC objects it requires.

[jitsu-code-review]

Reviewed the production Helm rendering, bootstrap hooks, credentials flow, and documented ingress setup.\n\nFindings:\n- The documented ingress-nginx TLS command does not provide a certificate source.\n- Switching an existing generated-secret install to auth.token replaces credentials without restarting the workloads.

[jitsu-code-review]

Reviewed the Helm production-mode manifests, credential/bootstrap hooks, ingress wiring, and rendered prod/dev charts.\n\nFinding:\n- Rotor is left without its inbound authentication variable in both generated and explicit-token production paths.

[jitsu-code-review]

Reviewed the production Helm rendering, credential/bootstrap paths, and ingress configuration.

Findings:

• The documented auth.token override reintroduces credentials into Helm-rendered state instead of supporting an external Secret reference.
• Revision-suffixed hook jobs are not removed by before-hook-creation, so they accumulate across upgrades.

[jitsu-code-review]

Reviewed the production-mode Helm rendering, bootstrap hooks, and published console image layout.\n\nFinding:\n- Upgrading an existing dev release to prod can leave the published console without its required credentials.

[jitsu-code-review]

Reviewed the production-mode Helm rendering, bootstrap hooks, and published console image layout.

Finding:

• Upgrading an existing dev release to prod can leave the published console without its required credentials.

[jitsu-code-review]

Reviewed the production Helm-mode changes, including rendered dev/prod manifests, image/entrypoint selection, ingress URL wiring, secret bootstrapping, and hook ordering. No additional actionable findings beyond the existing review threads.

[jitsu-code-review]

Reviewed the Helm dev/prod rendering, release hooks, service wiring, and ingress configuration.

Finding:

• The seed hook makes configurations with the console disabled fail after its five-minute wait.

[jitsu-code-review]

Reviewed the production-mode Helm rendering, image/entrypoint selection, secret bootstrap hooks, ingress wiring, and the unchanged default development path.

No additional actionable findings beyond the existing review threads. I also rendered the default generated-secret and explicit-token production configurations and ran Helm lint for production and development values.

[jitsu-code-review]

Reviewed the production/dev Helm renders, image entrypoints, bootstrap hooks, ingress validation, and the resolved review history.

Finding:

• The documented production dependency install needs to wait for readiness before installing the main chart.

[jitsu-code-review]

Reviewed the Helm production-mode changes, including image/scaffolding switching, generated and explicit credential paths, hook ordering, ingress rendering, and dependency startup guidance. Rendered the supported dev and prod configurations; no additional actionable issues found.

[jitsu-code-review]

Reviewed the production-mode templates, credential bootstrap hooks, ingress rendering, and dev/pinned-image render paths. One values-documentation issue is noted inline.

[jitsu-code-review]

Reviewed the production/dev Helm mode split, published-image selection, bootstrap secret and seed hooks, ingress wiring, and dependency service exposure. I also rendered the default production, explicit-token, ingress/TLS, external-console, and pinned-dev variants and linted both charts. No new actionable issues found; the previously raised review threads are resolved.

[jitsu-code-review]

Reviewed the Helm production-mode path, image/scaffolding selection, ingress configuration, credential bootstrap hooks, and dependency exposure changes. I also checked the existing review threads; all are resolved. No new actionable correctness, security, or user-visible regression findings.

[jitsu-code-review]

Reviewed the production-mode Helm path: published-image selection, service exposure and ingress, credential/bootstrap hooks, and dev deployment compatibility.

Finding:

• Production resource requests/limits cannot be configured, so namespaces that require them reject this new deployment path.

[jitsu-code-review]

[P2] The new prod path has no configurable resource requests or limits: the only workload resources: blocks are inside the dev-only build scaffolding, and values.yaml exposes no runtime resource settings. A namespace with a LimitRange that requires requests will reject every prod Pod (including the seed/token Jobs), and other clusters have no way to reserve capacity. Please add values-backed resource settings for the prod workloads (and pass them to the generated sync/function Pods where applicable), or make the required cluster policy an explicit prerequisite.

[sahiltyagi-jitsu]

Confirmed, and independently — this came out of the acceptance run on a real cluster before I saw this comment, so there are two separate paths to the same conclusion.

What the cluster showed:

• values.yaml exposes no resources key at all, so a client cannot set requests or limits without forking the chart.
• The prod render has no resources on any of the nine containers.
• Every pod therefore runs BestEffort, and a namespace with a LimitRange that requires requests rejects them outright, exactly as described.
• The same gap is in the sync pods syncctl generates, not just the chart. During the acceptance sync, Autopilot logged adjusted "cpu" resource to meet requirements for containers [oauth-refresh, pipes-init, sidecar].

Worth noting why this was invisible until now: the two clusters this chart has run on both hide it. Minikube has no pressure and no LimitRange. Autopilot injects defaults automatically — the autopilot-default-resources-mutator lines in the install log are it patching this in real time. A client cluster is a third environment, and it is the one the feature is for.

Not fixed here, deliberately. Adding values-backed resources means sensible defaults for nine containers plus the generated sync and functions-server pods, and touches helm-deps too. That is chart design rather than "add prod mode", and #1518 is already large with 18 earlier findings addressed. Raised with @ildar as a scope call — this or its own ticket. Leaving the thread open so the decision is visible rather than buried.

[jitsu-code-review]

Reviewed the production Helm rendering, image/entrypoint wiring, bootstrap hooks, service exposure, and the dependency-chart changes.\n\nFinding:\n- helm/templates/secrets.yaml: the explicit auth.token path reuses an inter-service bearer token as the NextAuth session-signing secret.

[jitsu-code-review]

[P1] JWT_SECRET must not be derived from the shared auth.token. The other fields here turn that value into bearer credentials (for example ROTOR_RAW_AUTH_TOKENS, CONSOLE_RAW_AUTH_TOKENS, and the service-admin-account: tokens) which are sent on service-to-service requests; webapps/console/lib/nextauth.config.ts uses JWT_SECRET as NextAuth’s signing secret. Anyone who obtains one of those bearer credentials can therefore forge console sessions, including an admin session. Keep the JWT secret independently configured/generated in this path (or require a separate auth.jwtSecret).

[sahiltyagi-jitsu]

Fixed in 9bf0705d7.

auth.jwtSecret is now a separate value, required whenever auth.token is set — the same pattern this template already uses for auth.seedPassword. The error message states that it must differ from auth.token and why, so it cannot be satisfied by pasting the same value in twice without noticing.

Two alternatives rejected, recorded here so they are not re-proposed:

• Hashing auth.token. The derivation would live in this chart, so anyone holding the token still obtains the signing secret. It buys nothing.
• Generating it in the template. lookup is empty during helm template, --dry-run and Argo CD rendering, so every reconciliation would emit a new secret and invalidate all sessions — the same reason this file does not generate the tokens themselves.

Scope check: this only ever affected the supplied-token path. The default generated path was already correct — token-generator.yaml mints JWT_SECRET with gen 48, independent of $TOKEN. Verified against a live install on a GKE cluster, where every key in jitsu-secrets differs from JWT_SECRET.

The old comment framed the reuse as a convenience — "one value, not two". That convenience was the vulnerability, and the comment now says so.

[jitsu-code-review]

Reviewed the production Helm rendering, credential bootstrap/upgrade flow, ingress configuration, and dev compatibility. One RBAC-scope finding is included inline.

[jitsu-code-review]

[P2] This create permission is not constrained to jitsu-secrets. Kubernetes cannot apply resourceNames to a create request because there is no existing object to authorize, so this ServiceAccount can create Secrets with any name in the release namespace. That contradicts the chart/README claim that the generator cannot touch other Secrets and broadens the impact of a compromised Job image. Please redesign this bootstrap so the generator does not need unrestricted Secret creation (or document and deliberately accept this broader grant).

[sahiltyagi-jitsu]

Correct, and the correction applies to my own wording as much as to the template — the README table I added in 33ce48914 said resourceNames stops the Job touching any other Secret, which is true of get and patch but not of create.

Addressed in 99955486f by stating the grant plainly rather than narrowing it, because it cannot be narrowed: Kubernetes does not apply resourceNames to a create request, since there is no object yet to authorize against. Whatever the Role says, that verb is namespace-wide.

The obvious alternative — pre-create an empty jitsu-secrets so the Job needs only patch — was considered and is worse. lookup is empty during helm template, --dry-run and Argo CD rendering (see the header comment in secrets.yaml), so a templated Secret would blank the live keys on every upgrade. Trading a namespace-scoped create for silent credential loss on upgrade is not a good trade.

So it stays, and is now documented in both places, with tokenGenerator.enabled=false named as the way out for anyone who cannot accept it. Happy to revisit if you would rather the bootstrap were redesigned — that is a larger change than this PR.

[jitsu-code-review]

Reviewed the production/dev Helm rendering paths, credential hooks, ingress validation, and dependency service exposure. Helm lint and representative dev and production renders succeed; invalid ingress configuration correctly fails rendering. No additional actionable findings beyond the existing open review threads.

[jitsu-code-review]

Reviewed the production Helm path, including rendered manifests, bootstrap hooks, image wiring, Ingress configuration, and credential handling.

Finding: auth.jwtSecret is documented as distinct from auth.token, but the template only requires a non-empty value and allows them to be identical.

[jitsu-code-review]

[P1] Enforce the JWT/token distinction instead of only documenting it. required only checks that auth.jwtSecret is non-empty: helm template ... --set auth.token=same-secret --set auth.jwtSecret=same-secret --set auth.seedPassword=... renders JWT_SECRET and the bearer-token variables with the same value. That recreates the session-forgery condition described in this comment. Add an eq guard that fails the render when the two values match.

[sahiltyagi-jitsu]

You are right, and the previous commit message overstated the fix — it claimed the error "cannot be satisfied by pasting the same value in twice without noticing". It could.

Confirmed by rendering rather than reading:

--set auth.token=sameval --set auth.jwtSecret=sameval
  RAW_AUTH_TOKENS: "sameval"
  JWT_SECRET:      "sameval"

required only proved non-empty, so the separate value bought documentation, not safety.

Fixed in b7eaae430 with an explicit eq guard that fails the render, naming which variables carry auth.token as a bearer credential and why sharing it with the session-signing secret is unsafe. Verified all three paths: equal values fail, different values render, and the generated path is untouched since it has no auth.token and mints an independent JWT_SECRET.

[jitsu-code-review]

Reviewed the production-mode Helm templates, rendered prod/dev pin configurations, and checked the console bootstrap path against its image entrypoint.\n\nFindings:\n- The token-generator hook does not select the release namespace, so default credential generation fails outside default.\n- Pinning the console image in dev disables the only seed path and leaves a fresh dev install without a login user.

[jitsu-code-review]

The Job may run in any release namespace, but every kubectl call here omits --namespace (or an equivalent -n {{ .Release.Namespace }}). kubectl therefore uses its default namespace, while the ServiceAccount Role/RoleBinding in this template are created in the release namespace. For helm install -n jitsu ..., the initial get fails and the subsequent create is forbidden in default, so the pre-install hook fails and the chart never installs. Please pass the release namespace to the get/patch/create calls (or set it once via KUBECTL_NAMESPACE).

[sahiltyagi-jitsu]

Not reproducible — this one is incorrect, and there is a live install that disproves it.

kubectl inside a pod uses in-cluster config, and in-cluster config takes its default namespace from /var/run/secrets/kubernetes.io/serviceaccount/namespace, which is the pod's own namespace. It does not fall back to default. So the Job's calls already act on the release namespace without --namespace.

Verified against the acceptance install on a GKE Autopilot cluster, which was helm install jitsu ./helm --set mode=prod -n jitsu:

• job/token-generator in ns=jitsu, succeeded=1
• secret/jitsu-secrets created in ns=jitsu with all 11 keys
• nothing created in default — secrets "jitsu-secrets" not found there

If the described failure were real, that install could not have completed; the pre-install hook would have failed before anything else ran.

Leaving it open rather than resolving, in case you are describing a case I have not thought of — happy to add -n {{ .Release.Namespace }} anyway as belt and braces if you would prefer it explicit.

[jitsu-code-review]

With mode=dev and images.console.repository set, this condition removes the source command that runs manage.ts seed. The pinned jitsucom/console image then uses docker-start-console.sh, which invokes manage.js seed only when SEED_DEMO_CONFIGURATION is nonempty; the dev values do not set it, and the prod-only seed Job is absent. A fresh dev install using the newly supported console image pin has a migrated database but no UserProfile, so the configured admin@example.com/changeme credentials cannot log in. Keep a no-demo seed path for a pinned dev console (or enable a dedicated seed hook for it).

[sahiltyagi-jitsu]

Correct, and confirmed by rendering it. Fixed in e4de4c0b0.

mode=dev with images.console.repository set fell between the two seed paths: the inline manage.ts seed lives in the source-build branch, and the seed Job was gated on mode=prod. Rendered before the fix:

	seed Job	inline seed
prod	yes	no	seeded
dev, unpinned	no	yes	seeded
dev, pinned console	no	no	nobody can sign in

The Job is now gated on whether the console runs from source rather than on mode, which covers all three. It already resolved its image through jitsu.image, so a pinned console image is used correctly. Re-rendered all three: prod via the Job, dev-unpinned inline, dev-pinned via the Job.

Worth noting this arrived with the PR — the per-service image override is one of the ticket's build requirements, so the configuration is newly supported here. My own behavioural check of the pin missed it because I pinned syncctl, which has no seeding role. Console is the one service where pinning has a side effect, and I picked the wrong service to test.

[jitsu-code-review]

Reviewed the Helm production-mode and image-pin changes, including rendered default production, explicit-token, and pinned-development paths.

Finding:

• P1: a pinned console image in development now creates the seed Job, but that Job is missing the development seed password, so a fresh install has no login user.

[jitsu-code-review]

[P1] This newly enables the Job for mode=dev with images.console.repository set, but the Job only calls jitsu.env and does not add the dev-only SEED_USER_PASSWORD (or JWT_SECRET) that console.yaml supplies through jitsu.devCredential. dev-deploy.sh creates jitsu-secrets with only the eight inter-service keys, so on a fresh pinned-dev install the rendered seed container has SEED_USER_EMAIL=admin@example.com but no password. seedUserAndWorkspace() then takes its no-op branch (profileCount === 0 && email && password), and the configured admin@example.com / changeme login does not exist. Add the same dev credential extra env to this Job (or source it from the Secret) for the pinned-dev path.

[sahiltyagi-jitsu]

Correct — the previous commit rendered the Job but left it unable to seed. Fixed in the commit above.

SEED_USER_PASSWORD and JWT_SECRET reach console.yaml through jitsu.devCredential, not through the Secret, because in dev dev-deploy.sh writes only the eight inter-service keys. The Job called jitsu.env alone, so it got SEED_USER_EMAIL and no password — seedUserAndWorkspace() then takes its no-op branch and creates nothing, which is the same outcome one step further along.

Now mirrors console.yaml. Rendered both paths:

dev + pinned console   EMAIL=Y PASSWORD=Y JWT=Y
prod                   EMAIL=Y PASSWORD=N JWT=N

Prod is unchanged on purpose: there the token-generator writes both keys into jitsu-secrets and the Job picks them up via envFrom, so devCredential correctly yields nothing.

[jitsu-code-review]

Reviewed the Helm production-mode changes, including image/scaffolding selection, secret bootstrap and rotation behavior, seeding, ingress configuration, and dependency exposure. I also rendered the default production, explicit-token production, and pinned-console development configurations.

No new actionable findings beyond the existing unresolved review threads.

[jitsu-code-review]

Reviewed the Helm prod/dev rendering, credential bootstrap paths, image-pinned dev behavior, and dependency exposure.

Finding: externally managed credential rotation does not trigger a coordinated workload rollout.

[jitsu-code-review]

[P2] With the documented external-secret path (tokenGenerator.enabled=false), secrets.yaml renders nothing, so every Deployment receives the same constant checksum/credentials value. Updating jitsu-secrets in the external manager therefore changes no pod template; envFrom is read only at pod start, so the first unrelated restart gets the new bearer token while the other services retain the old one and inter-service authentication fails. Could this path expose a rollout/version annotation that the secret controller/GitOps flow can bump (or document and wire in a reloader) so credential rotation is coordinated?