Gitpulse
Merged
Size
XS
Change Breakdown
Maintenance80%
Dependencies20%
#3432chore(helm): bump appVersion to v4.4.4

Helm chart versions bumped to 4.4.4

DE
devin-ai-integration
·Apr 23, 2026

The self-hosted Kubernetes configuration has been updated to version 4.4.4, rolling up over 500 upstream commits into a single upgrade without requiring manual database migrations.

Self-hosted users deploying via Kubernetes were previously pulling version 4.0.x images by default, missing out on hundreds of recent platform updates. The Kubernetes Helm chart configuration has been updated to point directly to the 4.4.4 release.

This update packages months of upstream work—spanning over 500 commits—into a straightforward drop-in upgrade. Because the webapp container automatically handles Prisma and ClickHouse schema updates during initialization, infrastructure operators can roll out the new version without pausing to run manual database migrations. All new environment variables introduced in the intervening releases include sane defaults, meaning existing deployments will continue to function immediately after applying the new chart.

Located in the Kubernetes hosting configuration, this bump brings self-hosted deployments up to parity with the hosted platform's current capabilities.

View Original GitHub Description

✅ Checklist

  • I have followed every step in the contributing guide
  • The PR title follows the convention.
  • I ran and tested the code works

Testing

Chart lint / template

  • helm dependency build + helm lint pass cleanly.
  • helm template renders successfully; the only diff vs. the 4.0.6 render is the chart labels and triggerdotdev/trigger.dev:v4.4.4 / triggerdotdev/supervisor:v4.4.4 image refs — no structural differences.

Fresh install on a local kind cluster

Ran hosting/k8s/setup-kind.sh → helm install trigger ./hosting/k8s/helm -n trigger on a single-node kind cluster (with a light resources override so everything fits on 2 CPU / 8 GB).

  • All 8 pods reach Running / Ready: webapp (2/2), supervisor, postgres, redis, clickhouse, electric, minio, minio-console.
  • Webapp init ran cleanly:
    • 757 Prisma migrations applied ("All migrations have been successfully applied.").
    • goose up on ClickHouse succeeded to schema version 28.
  • RUN_REPLICATION_ENABLED=1 established the logical-replication slot task_runs_to_clickhouse_v1 against the deployed Postgres automatically.
  • Supervisor registered against the webapp's bootstrap worker group (managed token synced via the token-syncer sidecar), WS connected to platform, failed-pod handler + pod-cleaner informers healthy.
  • All 6 helm test suites pass: test-clickhouse, test-electric, test-postgres, test-redis, test-s3, test-webapp (webapp /healthcheck green).

App-level compatibility audit (v4.0.4 → v4.4.4, 532 commits, 272 touching webapp/supervisor)

  • Webapp env audit (apps/webapp/app/env.server.ts): every newly added variable is either .optional() or has a default. Only CLICKHOUSE_URL is unconditionally required, and the chart already wires it via include "trigger-v4.clickhouse.url". Cross-checked in the reverse direction: no env var the chart currently sets has been removed or renamed (APP_LOG_LEVEL / DATABASE_HOST are still read via process.env, and CLICKHOUSE_PASSWORD is shell-substituted into CLICKHOUSE_URL when using an external-secret ClickHouse).
  • Supervisor env audit (apps/supervisor/src/env.ts): all new settings have defaults. The new conditional requirements in the superRefine (TRIGGER_METADATA_URL, TRIGGER_WORKLOAD_API_DOMAIN) only trigger when COMPUTE_SNAPSHOTS_ENABLED=true, which defaults off; TRIGGER_WORKLOAD_API_DOMAIN is already set by the chart unconditionally.
  • Supervisor ↔ webapp wire protocol (packages/core/src/v3/runEngineWorker/supervisor/ + apps/webapp/app/routes/engine.v1.worker-actions.*): only additive changes. The new ComputeWorkloadManager path is gated by the hasComputeAccess feature flag and COMPUTE_SNAPSHOTS_ENABLED, both off by default.
  • Run queue / Redis (#3219, fix(run-queue): prevent concurrency keys from bloating master queue shards): commit message explicitly calls out "Old-format entries drain naturally during rollout — no migration step needed, single deploy." No keyspace migration required.
  • ClickHouse schema: +22 new goose migrations between 4.0.4 and 4.4.4, all applied automatically on webapp container startup via docker/scripts/entrypoint.sh (no manual step).
  • Postgres schema: ~30 new Prisma migrations, applied automatically via db:migrate:deploy in the entrypoint. Includes one FK-drop migration (metadata-only, fast) and a covering index created CONCURRENTLY (non-blocking).
  • Electric: already pinned to 1.2.4 in the existing chart values.yaml; the webapp's Electric client was upgraded in-step.
  • Object Storage (#3275, seamless multi-provider migration): fully backwards-compatible. All existing OBJECT_STORE_* env vars remain optional with unchanged names. OBJECT_STORE_DEFAULT_PROTOCOL is an optional opt-in for zero-downtime migrations to new providers. Users who were working on v4.0.4 continue to work unchanged on v4.4.4.

Upgrade notes

None required. No manual migration, no breaking values/env-var change, and no new required configuration for existing deployments. First webapp rollout after upgrade will spend extra time applying ~30 Prisma + 22 ClickHouse migrations on startup; beyond the longer init window there's no operator action to take.

Changelog

Bump the Helm chart appVersion and version from v4.0.4 / 4.0.6 to v4.4.4 / 4.4.4 so users pull the latest released webapp and supervisor images by default, with chart version kept in sync with appVersion. No values.yaml changes are required — all new env vars introduced between 4.0.4 and 4.4.4 are optional or covered by existing chart defaults, and ClickHouse remains a required dependency wired end-to-end.

Link to Devin session: https://app.devin.ai/sessions/742fb351b3df4811b15ebaf1963669f4

© 2026 · via Gitpulse