リリース

Flux v2.9.1は、post-build変数置換がFlux自身のCRDスキーマを壊してしまう不具合を修正したパッチリリースです。あわせてSOPSの.ini復号とdry-run時のstrategic merge patchエラーも修正しています。新規の破壊的変更やCVEはありません。

• breaking変数置換によるCRDスキーマ破損を修正

  post-build変数置換を有効にしたKustomizationで、マニフェスト内の${...}がFlux CRDのスキーマフィールドと一致してしまうと、これまでのバージョンではCRDスキーマが壊れることがありました。v2.9.1ではFlux自身のCRDにkustomize.toolkit.fluxcd.io/substitute: disabledを付与し、置換の対象から除外しています。post-build置換を使っている場合はアップグレードを推奨します。

Flux v2.9.0 は機能拡張リリースです。CLI プラグインシステムやセキュリティ機能の充実など複数の新機能を導入する一方、image.toolkit.fluxcd.io/v1beta2 および notification.toolkit.fluxcd.io/v1beta2 の 2 つの API を廃止します。これらの API を使用しているマニフェストがある場合は、アップグレード前に v1 系への移行が必要です。

• breakingimage.toolkit.fluxcd.io/v1beta2 の廃止

  image.toolkit.fluxcd.io/v1beta2 を使用しているマニフェストまたはカスタムリソースは v2.9.0 では動作しません。v1 系 API へ移行してください。

• breakingnotification.toolkit.fluxcd.io/v1beta2 の廃止

  notification.toolkit.fluxcd.io/v1beta2 を使用しているマニフェストまたはカスタムリソースは v2.9.0 では動作しません。v1 系 API へ移行してください。

OpenKruise v1.9.0 adds several useful workload features and fixes a pile of stability bugs — including CPU-spike and panic fixes that affect anyone running ImagePullJobs or SidecarSets in production.

• breakingString-formatted maxUnavailable/maxSurge values now rejected by webhook

  Values like maxUnavailable: '5' (a quoted integer string) are now rejected at admission. If your manifests or Helm charts set these as strings instead of integers, the webhook will block them after upgrade. Audit your CloneSet and related workload specs before upgrading to v1.9.0.

• enhancementFix ImagePullJob high CPU before upgrading large clusters

  A cascading reconcile amplification bug was causing ImagePullJob controllers to spike CPU. If you've been seeing unexpected controller-manager CPU pressure, this is likely the cause. Upgrading to v1.9.0 should resolve it — no config changes needed.

• enhancementCloneSet progressDeadlineSeconds and OnDelete strategy now available

  CloneSet now supports progressDeadlineSeconds to surface stalled rollouts, and an OnDelete update strategy for manual upgrade control. Teams doing canary or phased rollouts with CloneSet should evaluate both options — progressDeadlineSeconds in particular fills a gap that previously required external monitoring to detect stuck updates.

Argo CD 3.4.4 is a patch release focused on stability fixes for health checks, RBAC, diffs, and template rendering. Update if you run multi-namespace setups or use Dex authentication.

• breakingRBAC regression fix for multi-namespace setups

  A prior release introduced a regression in RBAC enforcement for project-scoped resources in multi-namespace architectures. This patch restores correct behavior. If you use project-level RBAC restrictions across multiple namespaces, verify that access controls work as expected after upgrading, particularly around project-scoped resource visibility.

• enhancementHealth check reliability improvement

  The PromotionStrategy health check was incorrectly reporting Progressing after no-op re-hydration, blocking deployments. This is now fixed. If you use PromotionStrategy with ArgoCD, upgrade to avoid stalled health states that require manual intervention to clear.

• enhancementServer-side diff regression resolved

  A recent change broke server-side diffs on new objects, causing errors. This patch restores diff functionality. If you rely on server-side diffs in your deployment pipeline (especially for new resources), apply this update to restore normal diff behavior.

Argo CD v3.3.12 is a maintenance release fixing sync state tracking, cluster observer locking, configuration parsing, and git repository depth handling—no breaking changes.

• securityDex authentication now handles special characters in passwords

  Dex password parsing previously failed if passwords contained dollar signs, potentially locking users out. If you use Dex for OIDC and recently added or updated passwords with special characters, upgrade to v3.3.12 immediately to restore access. Test Dex login after updating.

• enhancementFix PromotionStrategy stuck state if using Argo Rollouts

  If you run Argo CD with Argo Rollouts and use PromotionStrategy, applications may have remained stuck in Progressing after configuration reloads even when nothing changed. Update to v3.3.12 to resolve this. Check your application health status post-upgrade to confirm recovery.

v1.52.0 has three breaking changes (discovery API default, immediate stitching removed, BUI union types) alongside significant catalog PostgreSQL performance fixes and a batch of UX and reliability improvements.

• breakingCheck discovery.endpoints and remove immediate stitching config

  Two breaking changes need attention before upgrading. First, if you use `discovery.endpoints` with internal-only string targets, convert them to object form with `target.internal` set to the internal URL and `target.external` set to a browser-reachable URL — otherwise the frontend will try to reach internal addresses directly. Second, remove `catalog.stitchingStrategy.mode: 'immediate'` from your config; it's now a no-op and will log deprecation warnings. Both changes are straightforward config edits.

• breakingMigrate ComboboxProps and SelectProps extensions before upgrading

  `ComboboxProps` and `SelectProps` are now union types. If your codebase has interfaces that extend either type, they will fail to compile — switch them to type intersections. Also audit CSS selectors that target list content as a direct child of `.bui-SelectPopover`, as that structure changed. These are frontend component-layer changes with no runtime fallback.

• enhancementCatalog query performance improvements for PostgreSQL — no action needed, just upgrade

  Several PostgreSQL-specific query planner fixes ship in this release: multi-column statistics on the search table, a dropped redundant index, tuned vacuum thresholds, and a split count/list query. If your catalog list views are slow with large entity counts, this upgrade is worth prioritizing. No config changes needed — the improvements apply automatically via migration. Teams on MySQL/SQLite won't see the same gains.

flagd core v0.16.0 changes disabled flag evaluation from an error response to a successful resolution with reason=DISABLED, affecting gRPC/OFREP callers and code that inspects evaluation metadata.

• breakingAudit any code that checks errorCode or reason on flag evaluations

  If your code branches on FLAG_DISABLED error codes or checks the reason field from direct gRPC/OFREP responses, it will no longer receive that error path for disabled flags — it'll get a success with reason=DISABLED instead. Search your codebase for FLAG_DISABLED string matches, error-code switch statements, and reason-field conditionals before upgrading. SDK users who only consume the resolved value are unaffected and can upgrade without changes.

• enhancementUse reason=DISABLED for observability and audit logging

  The new behavior is actually cleaner for telemetry. Since disabled flags now resolve successfully, you can distinguish 'flag disabled' from 'evaluation error' in your metrics and logs without special-casing error codes. Update your dashboards and alerting rules to treat reason=DISABLED as an expected, non-error signal rather than filtering it out as noise.

flagd v0.16.0 changes disabled flag evaluation from an error to a successful resolution with reason=DISABLED, affecting direct gRPC/OFREP callers and code that inspects evaluation metadata.

• breakingAudit error-handling code that checks FLAG_DISABLED or errorCode

  If your application checks the evaluation reason or error code after a flag resolution — whether through direct gRPC calls, OFREP HTTP calls, or Go imports of core/pkg/model — you need to update that logic. FLAG_DISABLED errors will no longer appear; instead expect a successful response with reason=DISABLED. SDK users who only read the resolved value are unaffected, but any monitoring, alerting, or branching logic that keys off FLAG_DISABLED will silently stop triggering. Grep your codebase for FLAG_DISABLED and errorCode checks before upgrading.

Flux v2.8.8 patches two go-git CVEs in source and image-automation controllers, fixes a memory leak in helm-controller, and adds GCP sovereign cloud registry support.

• securityUpgrade immediately to patch two go-git CVEs

  CVE-2026-45571 and CVE-2026-45570 affect source-controller and image-automation-controller. Both are fixed in go-git v5.19.1 bundled with this release. If you run either of these controllers — and most Flux installations do — upgrade to v2.8.8 now. There's no workaround short of disabling those controllers.

• breakingReview charts that place non-CRD resources under crds/ directory

  Helm-controller previously force-applied any object found under a chart's crds/ directory, not just actual CRDs. That behavior is now corrected. If you have Helm charts (especially community or third-party ones) that bundle non-CRD manifests under crds/ as a workaround for install ordering, those objects will no longer be force-applied. Audit your HelmRelease resources and test in a non-production environment before rolling this out broadly.

• enhancementInvestigate artifact fetch timeouts if reconciliations have been stalling

  The new configurable HTTP timeout for artifact fetching directly addresses indefinite blocking during fetches. If you've seen helm-controller or source-controller reconciliations hang without clear errors, this fix likely explains it. After upgrading, configure the timeout explicitly rather than relying on defaults — check the helm-controller v1.5.5 changelog for the specific field name. Also worth auditing memory usage before and after upgrade if your helm-controller pods have been growing steadily in memory.

v1.51.0 lands six breaking changes alongside major catalog performance wins, a new AiResource entity kind, and MCP/OIDC hardening. Plan migration time before upgrading.

• breakingRun catalog DB migration SQL before deploying to large installs

  The new catalog migration adds covering indices and a UNIQUE constraint on the search table, which can be slow on large datasets. The release notes explicitly recommend running the provided SQL commands manually before deploying v1.51.0. Skipping this turns a controlled maintenance window into an uncontrolled deployment stall. Check the changelog for the exact SQL before you upgrade.

• breakingAudit six breaking changes before upgrading — OIDC and MsgGraph need immediate config review

  The OIDC CIMD/DCR patterns changed from wildcard '*' to specific MCP client defaults — any custom MCP clients will silently stop working unless you explicitly add their patterns to the allow list. Separately, Microsoft Graph now excludes disabled user accounts; if your org tracks disabled users in Backstage, add an explicit filter before upgrading. Also migrate NavItemBlueprint usages to PageBlueprint title/icon params, and update PolicyQueryUser code to use credentials instead of the removed token/expiresInSeconds fields.

• enhancementAdopt incremental Microsoft Graph ingestion for large orgs

  The new msgraph-incremental module processes users and groups one page at a time and persists cursor state, meaning a pod restart no longer forces a full re-ingest. For orgs with tens of thousands of users, this is a practical operational improvement worth switching to. Install the new module and migrate your provider config — the old MicrosoftGraphOrgEntityProvider remains available but holds the full dataset in memory.

pack v0.40.6 is a small patch fixing a trust detection bug in 'builder inspect' and adding Heroku's builder:26 to the trusted builders list.

• breakingAudit pipelines that worked around the trust detection bug

  If your CI scripts or automation added extra flags or workarounds because 'builder inspect' was misreporting trusted builders as untrusted, remove those workarounds now. Running with unnecessary trust overrides is a security smell worth cleaning up.

• enhancementUse heroku/builder:26 without manual trust configuration

  Teams targeting Heroku's stack 26 no longer need to manually mark the builder as trusted via '--trust-builder' or config file entries. Upgrade to v0.40.6 and clean up any explicit trust overrides you've added for this builder.

Argo CD v3.3.10 is a patch release fixing a nil-pointer panic in permission validation, a log line UI overflow bug, and bumping Go to 1.25.9 to address CVEs.

• securityUpgrade immediately — Go 1.25.9 fixes CVEs in the runtime

  The Go runtime was bumped from a prior version to 1.25.9 specifically to resolve CVEs. The release notes don't enumerate the CVE IDs, but any patch that upgrades the runtime for security reasons on a stable branch deserves prompt action. If you're running 3.3.x, upgrade to 3.3.10 now rather than waiting for your next maintenance window.

• breakingServer-side diff now correctly hides secrets — verify diff outputs if you rely on them

  The fix to apply HideSecretData to server-side diff results means that previously exposed secret values in diff views will now be redacted. If any automation, alerting, or audit tooling parses diff output expecting raw secret values, it will break. Review your diff-dependent workflows before upgrading.

• enhancementNil APIResource panic fix prevents unexpected controller crashes

  The permission validator could panic when an APIResource was nil — a condition that can occur with certain custom or non-standard API groups. If you've seen intermittent ArgoCD controller restarts without clear cause, this is a likely culprit. Upgrade to 3.3.10 to stabilize those environments.

Argo CD v3.4.2 is a patch release fixing a panic in the permission validator, reverting a problematic revision update optimization, and patching secret data exposure in server-side diffs.

• securitySecret values could appear in diff output — patch now

  Server-side diff results for Secret resources were not having HideSecretData applied, meaning secret values could be exposed in diff views through the UI or API. If you use server-side apply or server-side diff previews, upgrade to 3.4.2 immediately. Audit your ArgoCD API access logs if you suspect exposure.

• breakingUpdateRevisionForPaths revert may re-introduce previous behavior

  The optimization that avoided unnecessary UpdateRevisionForPaths calls (merged in 3.4.x) caused regressions and has been reverted. If you were relying on that behavior for performance or correctness, expect the pre-fix behavior to return. Monitor sync operations after upgrading, especially for path-filtered applications.

• enhancementPermission validator panic fix improves stability

  A nil APIResource in the permission validator could crash the ArgoCD server process. This is now guarded. If you've seen unexpected pod restarts on the ArgoCD server, especially in environments with non-standard CRDs or API aggregation, this patch likely addresses it.

Flux v2.8.7 patches a CVE in go-git and fixes a destructive reconciliation bug where non-namespaced resources with ssa:IfNotPresent were being deleted and recreated every cycle.

• securityPatch CVE-2026-45022 by upgrading now

  go-git v5.19.0 fixes CVE-2026-45022, which affects source-controller and image-automation-controller — two components that actively clone and interact with Git repos. If your Flux installation pulls from any external or semi-trusted Git source, treat this as a priority upgrade. Run 'flux install' or update your Helm release to v2.8.7 immediately.

• breakingCheck non-namespaced resources using ssa:IfNotPresent for unintended churn

  If you're managing ClusterRoles, CRDs, or other cluster-scoped resources with the kustomize.toolkit.fluxcd.io/ssa: IfNotPresent annotation, those resources were being silently deleted and recreated on every reconciliation loop before this fix. Audit your Kustomization objects and verify resource state after upgrading to confirm the churn has stopped. Any dependent workloads may have experienced disruptions you weren't aware of.

• enhancementFollow the v2.7+ upgrade procedure if coming from v2.6

  The Flux team has a specific upgrade discussion thread for v2.7+ migrations. Skipping it when jumping from v2.6 to v2.8.7 can cause issues. Review the linked procedure before applying this update in environments running older Flux versions.

Argo CD 3.4.1 is the first 3.4 release (skipping 3.4.0), bringing a breaking cluster version format change for ApplicationSets, plus a large wave of bug fixes, performance improvements, and UI enhancements.

• securityAdd X-Frame-Options/CSP headers and JWT logout invalidation

  Two security fixes landed: Swagger UI endpoints now return X-Frame-Options and Content-Security-Policy headers (mitigates clickjacking), and JWT tokens are invalidated server-side on logout (prevents session reuse after logout). Both are passive — no config changes needed — but if you run Argo CD behind a reverse proxy that strips security headers, verify the headers reach clients after upgrading.

• breakingUpdate ApplicationSet cluster version labels before upgrading

  The kubernetes-version label format changed from Major.Minor (e.g., '1.29') to vMajor.Minor.Patch (e.g., 'v1.29.3') to match Helm 3.19.0. If you use ApplicationSet Cluster Generators with argocd.argoproj.io/auto-label-cluster-info, your existing cluster secrets carry the old format. After upgrading, update those secrets to use argocd.argoproj.io/kubernetes-version with the new format, or your cluster-version-based filters will stop matching. Check the 3.3-3.4 upgrade guide before rolling out.

• enhancementAppSet controller and repo-server performance improvements worth monitoring

  Several perf fixes shipped: optimized parentUIDToChildren data structure, reduced secret deep-copies in the controller, parallel batching in CLI server-side diff, and optimized repoLock on checkout. If you've been seeing slow reconciliation or high CPU in the appset controller on large clusters, this upgrade should show measurable improvement. Monitor controller CPU and reconciliation latency metrics after rollout.

flagd core v0.15.5 fixes evaluation correctness bugs in fractional rollouts and JSONLogic and/or operators — teams relying on complex flag targeting rules should upgrade.

• securityDependency security alerts resolved

  Dependabot security alerts were resolved in this release. No CVEs are called out explicitly, but the dependency updates address known vulnerabilities in transitive deps. Upgrade if you're running flagd in a security-sensitive environment.

• breakingFractional evaluator fix: upgrade if you use targeting keys

  Null or missing targeting keys in fractional evaluators previously caused undefined behavior. If your flag rules use fractional/percentage rollouts and some users may lack a targeting key (e.g. anonymous users), upgrade to avoid incorrect bucket assignments.

• breakingJSONLogic and/or bug fix may change evaluation results

  The jsonlogic and/or operator bug could cause flag rules with compound boolean logic to evaluate incorrectly. Review any rules relying on and/or conditions after upgrading — results may change from what you saw in v0.15.4.

v3.3.9 is a focused patch addressing four bugs — including a panic in ApplicationSet DuckType Generator and a UI crash in pod logs — plus a Go version bump to resolve CVEs.

• securityUpgrade to patch Go-level CVEs

  The Go runtime was bumped specifically to resolve CVEs. The release notes don't enumerate the exact CVE IDs, but if you're running 3.3.x in production, upgrade to 3.3.9 now rather than waiting for your next maintenance window. All container images are cosign-signed and SLSA Level 3 provenance is available — verify signatures before deploying if your pipeline requires it.

• breakingApplicationSet DuckType Generator panic is now fixed — review affected ApplicationSets

  If you use DuckType Generators and have clusters with non-string label values, previous versions would silently panic. After upgrading, those ApplicationSets will now process correctly rather than crashing. Do a quick audit of your ApplicationSet resources post-upgrade to confirm they're reconciling as expected — you may see previously-failing sets suddenly become active.

• enhancementOCI metadata caching restored — expect reduced registry pressure

  The Redis cache for OCI metadata was broken, meaning every OCI source lookup was hitting the registry directly. With this fix, caching works again. If you use OCI-sourced ApplicationSets or Helm charts, you should see reduced latency and fewer registry requests after upgrading. No configuration change needed.

Microcks 1.14.0 adds Kafka request-reply for async mocking and expands Callback/Sync-to-Async support across REST, gRPC, and the UI. A bug fix prevents HTTP method mutation on mocked operations.

• securityRebuild custom images on updated UBI9 base

  The base image bumps to UBI9 9.7-1776833838. If you build custom Microcks images on top of the official one, rebuild and re-test after upgrading to pick up the upstream OS patches included in this UBI update.

• breakingVerify REST mock routing after operation method fix

  The fix for issue #2028 prevents the operation HTTP method from being overridden — a subtle bug that could cause mocks to respond incorrectly if the method was being mutated. Verify any existing REST mocks that rely on method-specific routing to confirm they behave as expected after upgrade.

• enhancementAdopt Kafka request-reply for async testing

  Kafka async mocks now support request-reply semantics. If your team uses Microcks to mock event-driven services over Kafka, this unlocks proper two-way interaction testing without external tooling. Review the updated API for Callback and Sync-to-Async support alongside the new triggers UI before migrating existing Kafka mock setups.

Argo CD v3.3.8 is a patch release with six bug fixes targeting core mode syncs, AppSet resource limits, CLI diff accuracy, and informer cache staleness.

• breakingRefresh behavior changed again — validate your autosync pipelines

  The revert of the informer resync fix means refresh behavior is back to pre-3.3.7 state. If you tuned anything around reduced refresh frequency after upgrading to 3.3.7, re-examine those assumptions. Check autosync event logs to confirm expected behavior before promoting to production.

• enhancementCore mode users: upgrade immediately to unblock syncs

  The missing server.secretkey bug caused silent sync failures in core mode deployments — a serious operational gap that's easy to miss in monitoring. If you run Argo CD in core mode, this patch is not optional. Upgrade, then verify sync status across all applications post-upgrade.

• enhancementLarge ApplicationSets now default to 5,000 resource status entries

  If you manage ApplicationSets with hundreds of apps, you may have hit the old resource status count ceiling without realizing it. After upgrading, review any ApplicationSets that showed truncated or missing resource statuses and confirm they now report correctly.

Argo CD v3.2.10 is a pure bug-fix patch that resolves five regressions, including a critical core-mode sync failure and a stale cache issue in RevisionMetadata.

• breakingCore-mode deployments: upgrade immediately if apps are stuck out-of-sync

  If you run Argo CD in core mode (no API server) and recently saw apps failing to sync with secret-related errors, the missing server.secretkey bug was silently blocking all syncs. Upgrade to v3.2.10 and verify affected apps reconcile cleanly afterward.

• breakingAutosync event message format reverted — re-check any alerting rules you updated

  A message format change introduced recently and then reverted means the autosync event messages are back to their original format. If you updated Prometheus alerting rules, Grafana queries, or log parsers to match the new format, roll those changes back before upgrading to avoid false positives or missed alerts.

• enhancementsourceHydrator users: upgrade to get correct app diff behavior

  The CLI was using the wrong source revision for app diff and manifests commands when sourceHydrator was in use, meaning you could be reviewing diffs against the wrong state. After upgrading, re-run any diff checks you performed on v3.2.9 to confirm the output is accurate.

Patch release with two targeted bug fixes: a revert of a problematic refresh prevention change and a core mode sync failure when server.secretkey is absent.

• breakingRevert of refresh-prevention fix may re-expose original behavior

  The cherry-picked fix for preventing automatic refreshes from informer resyncs and status updates was reverted because it caused problems in 3.1. If you upgraded to 3.1.x specifically expecting that behavior to be fixed, it's gone again. Watch the upstream issue for a corrected implementation before relying on it. No action needed otherwise, but be aware of potential extra refresh churn in large clusters.

• enhancementUpgrade immediately if running Argo CD in core mode without server.secretkey

  A bug caused the application controller to fail syncing entirely when running in core mode and the server.secretkey was absent from the cluster secret. If your core-mode installations have ever had intermittent sync failures that were hard to diagnose, this is likely the culprit. Upgrade to 3.1.15 and verify syncs resume normally after rollout.

Flux v2.8.6 is a patch release fixing helm-controller post-renderer conflicts, a notification-controller regression for generic providers, and adding a MigrateAPIVersion feature gate in kustomize-controller.

• breakingAdd 'audience' to GCR Receiver secrets before upgrading to v2.9

  The 'audience' field on GCR Receiver secrets is currently optional but will become mandatory in v2.9. Audit your Receiver resources now and add the audience field to any GCR-backed secrets. Doing this proactively prevents a hard failure on your next major upgrade.

• breakingGeneric provider commit status events were broken — upgrade immediately if you rely on them

  A regression in notification-controller stopped generic providers from forwarding commit status events. If your CI/CD pipelines depend on those webhooks for pipeline gating or observability, they have been silently failing since the prior release. This patch restores that behavior — upgrade to v2.8.6 without delay.

• enhancementUse MigrateAPIVersion feature gate when managing resources with deprecated API versions

  If kustomize-controller manages resources that use older API versions tracked in managed field entries, the new MigrateAPIVersion feature gate handles migration automatically. Enable it in environments where you're seeing API version drift or drift detection noise from deprecated APIs.

Argo CD v3.3.7 is a patch release fixing controller performance regressions, OIDC config handling, and several UI/security header issues.

• securitySwagger UI endpoints now have clickjacking protection — upgrade if exposed

  X-Frame-Options and Content-Security-Policy headers were missing from Swagger UI endpoints. If your Argo CD API server is reachable from browsers (even internally), those endpoints were frameable. Upgrade to 3.3.7 to close this. No config change needed post-upgrade.

• breakingOIDC auth may behave differently after upgrade if config was stale

  The fix ensures OIDC config reloads on server restart rather than using a cached/stale version. In practice this is a correctness fix, but if you've been working around stale OIDC behavior with manual pod restarts, verify SSO flows after upgrading to confirm expected behavior.

• enhancementUpgrade if you're seeing excessive reconciliation or controller CPU spikes

  Two separate fixes address controller overhead: the parentUIDToChildren data structure change reduces memory churn on large clusters, and the informer resync fix stops unnecessary app refreshes that inflate API server load. If your controller is burning CPU or you're seeing constant reconcile loops, this patch is worth prioritizing.

v1.50.0 is a wide-ranging release with several breaking changes across auth, frontend APIs, and catalog. Key practical upgrades: AWS RDS IAM auth, Auth0 federated logout, catalog deadlock fixes, and security patches for rollup/glob.

• securityUpdate CLI and build tooling to pick up rollup path traversal fix

  rollup < v4.59 has a high severity path traversal vulnerability (GHSA-mw96-cpmx-2vgc). The @backstage/cli, repo-tools, and several CLI modules have been updated. Run the upgrade helper and update your lockfile. If you pin rollup versions anywhere in your workspace, update those pins to v4.59+. The glob dependency was also bumped to v13 to address vulnerabilities in v7/v8/v11.

• breakingVerify token decoding code before upgrading — ent claim removed by default

  auth.omitIdentityTokenOwnershipClaim now defaults to true, so Backstage user tokens no longer include the ent ownership claim. Any code that manually decodes tokens and reads ent will silently get nothing. Audit your codebase for raw token decoding and replace it with the userInfo core service. If you need time, set auth.omitIdentityTokenOwnershipClaim: false in your config temporarily, but plan to remove it — the setting will be dropped in a future release.

• breakingMigrate createSchemaFromZod to configSchema before upgrading frontend-plugin-api

  The deprecated createSchemaFromZod helper is gone in @backstage/[email protected]. Any extension or blueprint using it will fail at runtime. Check the 1.50 migration docs at backstage.io/docs/frontend-system/architecture/migrations#150 and switch to the configSchema option. Note that plain zod v3 schemas are not supported — use import { z } from 'zod/v4' from the zod v3 package or upgrade to zod v4.

Flux v2.8.5 patches a cache race condition that could freeze Kustomizations, fixes Azure Blob prefix handling, and adds GCR Receiver verification fields.

• breakingStuck Kustomizations? This patch likely fixes you

  If you've seen Kustomizations get stuck after a reconciliation timeout or cancellation — often requiring a manual flux reconcile or pod restart to unblock — the race condition fix in kustomize-controller v1.8.3 directly addresses this. Upgrade to v2.8.5 and monitor your reconciliation loops post-upgrade. No config changes needed, but watch for Kustomizations that were previously stuck to automatically recover.

• breakingVerify Azure Blob prefix filtering actually works after upgrade

  If you're using Bucket sources backed by Azure Blob Storage with a prefix configured, that prefix was not being applied — meaning your source-controller was fetching more objects than intended. After upgrading to v2.8.5, the prefix filter will now take effect. Validate that your expected subset of blobs is still being synced correctly and that no previously-ignored paths break your deployments.

• enhancementTighten GCR webhook security with email and audience verification

  The GCR Receiver now accepts optional 'email' and 'audience' fields. If you're using GCR image push webhooks to trigger Flux reconciliation, add these fields to your Receiver spec to validate the service account identity and token audience — reducing the risk of forged webhook requests. This is opt-in, so existing setups won't break, but teams with strict security postures should configure it.

Flux v2.8.4 is a CLI-only patch fixing two bugs: Windows compatibility for 'flux build/diff ks' and source flag validation in 'create kustomization'.

• breakingCheck your 'create kustomization' scripts for invalid --source values

  The '--source' flag now validates input properly. Scripts or pipelines passing malformed source references that previously slipped through will now fail explicitly. Test your automation before rolling out the updated CLI in CI/CD pipelines.

• enhancementWindows users: upgrade to unblock 'flux build/diff ks'

  If your team uses Windows workstations or CI runners for Flux kustomization diffs, these commands were silently broken. Upgrade the CLI to v2.8.4 — the fix is CLI-side only, so no cluster-side changes are needed.

Argo CD v3.3.6 is a focused bug-fix patch addressing a false-positive diff detection during app normalization and a wrong installation ID returned from cache.

• breakingCheck for ghost sync loops before upgrading

  If your ArgoCD controller has been triggering unexpected syncs or showing phantom diffs on apps that haven't changed, this patch fixes that normalization bug. Upgrade to 3.3.6 promptly if you're seeing this — it's a common source of noisy alerts and wasted reconciliation cycles.

• enhancementRoutine patch — safe to apply quickly

  This is a two-bug patch with no schema changes, no API changes, and no migration steps. If you're already on 3.3.x, roll this out through your normal process. No special precautions needed.

A targeted patch release fixing a gRPC CVE, a false-diff bug in app normalization, and a UI glitch in RollingSync — upgrade promptly for the security fix alone.

• securityPatch CVE-2026-33186 by upgrading to v3.2.8 now

  The grpc-go CVE-2026-33186 fix is the primary reason to move quickly on this release. If you're running any 3.2.x version, upgrade to 3.2.8. Verify your container images using cosign against the published provenance — the Argo CD docs cover the exact verification steps. Don't wait on this one.

• breakingCheck for spurious sync operations before and after upgrade

  The normalization diff bug could have been silently triggering syncs on apps that were actually in-sync. After upgrading, review your sync history for apps that synced frequently without visible config changes — those were likely false positives. The fix should stop them, but any automation or alerts built around sync frequency may need recalibration.

• enhancementRollingSync UI fix improves progressive delivery visibility

  If you use ApplicationSets with RollingSync and have ever wondered why a step appeared blank or unclear in the UI, this fix addresses that. No action needed beyond upgrading, but it's worth re-examining your RollingSync step configurations in the UI post-upgrade to confirm everything displays as expected.

Argo CD v3.3.5 is a patch release fixing a stack overflow bug, hook ordering issues, and UI improvements — low risk, high value to upgrade.

• breakingCircular ownerRef crash is now fixed — upgrade if you hit mysterious crashes

  If your cluster has resources with circular ownership references (common in some operators or misconfigured CRDs), Argo CD could stack overflow and crash during graph processing. This is now fixed. If you've seen unexplained application-controller crashes, this is almost certainly the cause. Patch immediately.

• breakingPostSync hooks silently skipped when PreDelete/PostDelete hooks coexist — fixed

  Workflows relying on PostSync hooks for notifications, cleanup, or validation were silently broken if the same app also defined PreDelete or PostDelete hooks. Verify your hook-based pipelines after upgrading to confirm they now execute correctly.

• enhancementgrpc dependency bumped to 1.79.3

  The grpc library was bumped from 1.77.0 to 1.79.3. This picks up several upstream fixes. No action required beyond upgrading, but if you run Argo CD in a security-sensitive environment, review the grpc changelog for any CVEs addressed in that range.

v1.49.0 is a landmark release: the New Frontend System hits 1.0 RC, the CLI becomes extensible via modules, and there are multiple breaking changes in UI components, integrations, and entity cards requiring migration work.

• breakingMigrate entity cards and BUI components before upgrading `@backstage/plugin-catalog`

  The major version bump on `@backstage/plugin-catalog` means direct action is required. Remove all `variant` prop usage from EntityAboutCard, EntityLinksCard, EntityLabelsCard, GroupProfileCard, and UserProfileCard. Wrap your app in a `BUIProvider` inside a React Router context — without it, Link, ButtonLink, Tabs, Menu, and Table lose client-side navigation. Also rename any CSS selectors using old `bui-HeaderPage` class patterns and camelCase data attributes. Audit custom components that implement the old `Checkbox` `selected`/`indeterminate` props and switch to `isSelected`/`isIndeterminate`.

• breakingRemove all deprecated Bitbucket and legacy integration config immediately

  The old `bitbucket` config key and Azure DevOps `token`/`credential` fields are gone — not deprecated, gone. If your `app-config.yaml` still references these, your backend will fail to start after upgrading. Replace `bitbucket` with `bitbucketCloud` or `bitbucketServer`, migrate Azure DevOps to the `credentials` array, and update any Gerrit URL utility calls. Check scaffolder templates too, as `parseRepoUrl` no longer handles `bitbucket`.

• enhancementAdd `@backstage/cli-defaults` as a devDependency now, not later

  The CLI module system is live, and the fallback to built-in commands already emits a deprecation warning. Add `@backstage/cli-defaults` to your root `devDependencies` today to silence the warning and future-proof your setup before the fallback is removed entirely. If you maintain custom CLI tooling, look at `createCliModule` in `@backstage/cli-node` to package it properly as a first-class CLI extension.

Flux v2.8.3 fixes a critical helm-controller regression that broke templating for charts containing YAML separators or embedded content.

• breakingUpgrade immediately if using Helm charts with YAML separators

  The regression in v2.8.2 breaks templating for common chart patterns like multi-document YAML files and embedded scripts. Review your Helm deployments for failures and upgrade to v2.8.3 now. Follow the official upgrade procedure for Flux v2.7+ to avoid migration issues.

• enhancementValidate Helm chart deployments after upgrade

  After upgrading, check that previously failing Helm releases now deploy successfully. Pay special attention to charts that embed certificates, scripts, or use multiple YAML documents. This fix restores functionality that may have silently failed in recent versions.

Argo CD 3.3.4 delivers critical bug fixes for token refresh handling and git-lfs support, plus enhanced security documentation - a maintenance release that improves operational stability.

• securityVerify signed release assets

  All container images now include cosign signatures and SLSA Level 3 provenance. Use the official verification documentation to validate your container images before deployment, particularly in security-sensitive environments.

• breakingReview token refresh configurations

  The token refresh fix resolves parsing errors that could affect component behavior. Check your existing token configurations and monitor for any authentication issues after upgrading, especially in multi-component setups.

• enhancementUpgrade for ppc64le architecture support

  If running on ppc64le systems, this release fixes git-lfs functionality that was previously broken due to missing checksums. Plan your upgrade to restore full git-lfs capabilities on these architectures.

Flux v2.8.0 introduces major GitOps capabilities including Helm v4 support, enhanced observability, faster recovery times, and improved notification features while removing deprecated APIs.

• breakingMigrate from deprecated v1beta2/v2beta2 APIs immediately

  Deprecated APIs have been removed from CRDs. Follow the official upgrade procedure for Flux v2.7+ to migrate your resources to supported API versions before upgrading to v2.8.0.

• enhancementEnable faster application recovery with new feature gate

  Activate the CancelHealthCheckOnNewRevision feature gate on your Kustomizations and HelmReleases to reduce recovery time during application failures by canceling health checks when new revisions are detected.

• enhancementImplement automated PR notifications for GitOps workflows

  Configure Pull Request commenting in your notification providers to enable direct feedback from Flux deployments to development teams, improving visibility and collaboration in GitOps workflows.

Argo CD v3.3.2 fixes the critical client-side apply migration issue that affected self-managed installations in v3.3.0/v3.3.1, requiring specific upgrade steps for users managing Argo CD with itself.

• breakingEnable ServerSideApply for Self-Managed Installations

  If you have an Argo CD Application managing your Argo CD installation, you must enable `ServerSideApply=true` sync option on that Application before upgrading to v3.3.2. This is required for the upgrade to succeed and prevents apply migration failures.

• breakingRemove Temporary ClientSideApplyMigration Setting

  If you previously upgraded to v3.3.0/v3.3.1 and set `ClientSideApplyMigration=false` as a workaround, remove this setting after upgrading to v3.3.2. Keeping it may cause field manager conflicts with other Kubernetes controllers.

• enhancementSafe Upgrade Path for Previously Affected Users

  Users affected by the v3.3.0/v3.3.1 client-side apply migration bug can now safely upgrade to v3.3.2. Follow the upgrade guide carefully and test the upgrade process in a non-production environment first, especially for self-managed installations.