Helm Chart History¶

Release notes for each Helm chart utilised by Boards

Important

As of January 2023 we have moved our image hosting. Please follow this guide to configure your Kubernetes with access to our images hosted in Quay.io.

MinIO image removed from Docker Hub

Every huddo-boards-cp chart before 2.6.0 pulls MinIO from Docker Hub, where the image is no longer available. MinIO is discontinued. If you use MinIO, upgrade to 2.6.0 or later, or apply the workaround, and migrate to SeaweedFS.

For Component Pack¶

huddo-boards-cp¶

Danger

As of huddo-boards-cp 2.0.0 we have migrated from ingress-nginx to Traefik. Please follow our migration guide.

Tip

As of huddo-boards-cp 2.1.0 we have added SeaweedFS S3 storage with a migration path from MinIO. We recommend this as a replacement for MinIO. See SeaweedFS migration guide.

Version	Description	Breaking Changes
1.0.0	Initial release (Huddo)	No
1.1.0	CNX 8 fix for Mongo 5	No
1.1.1	Support custom `storageClassName` instead of PV	No
1.2.0	Added readiness probes on each service	No
1.2.1	Fix ingress session cookie `SameSite` setting (polling in a CORS frame, e.g. Teams)	No
1.3.0	Support CNX 8 Mongo 7 (use ConfigMap `mongo-name` instead of `mongo5-rs-members-hosts`) with images after `2025-02-13`	No
1.3.1	Change `ingress.pathType` to `ImplementationSpecific` to allow regex rewrites	Potentially – may affect ingress matching behaviour
1.4.0	Support CNX 8 CR13 cache rename - new environment variables in ConfigMap and Secret references	No
2.0.0	Move from ingress-nginx to traefik	Yes – migration required
2.1.0	Add SeaweedFS S3 storage with migration path from MinIO	Optional – migration only if adopting SeaweedFS
2.2.0	Merge activity-migration as optional component (`migration.enabled`, default `false`)	No – uninstall the standalone activity-migration release before enabling
2.3.0	Auto-create secrets: CA bundle mount (`global.internalCa`), `extraObjects`, and `imageCredentials` (image pull secret)	No
2.3.1	Drop legacy support for removed `v1beta1` APIs (Deployment, Ingress, PodSecurityPolicy)	No
2.3.2	Drop deprecated Traefik `StripPrefix` `forceSlash` option (clears the `ForceSlash` deprecation warning in Traefik logs; no behaviour change)	No
2.3.3	SeaweedFS migration Job now verifies the sync and prints a report (totals, missing, size mismatch, orphans) to its logs (`s3.migration.verify`, default `true`); completed Job kept for 1h so the report stays readable	No
2.3.4	Pod annotations for service mesh injection: `global.podAnnotations` applies to every pod, per-component `podAnnotations` merge on top, and `s3.jobPodAnnotations` lets the S3 Job pods opt out of the mesh	No – defaults render unchanged
2.3.5	SeaweedFS now runs as user `1000` instead of `root` (matches MinIO; fixes startup `permission denied` on NFS exports with `root_squash`). The data directory is chowned automatically on start (`s3.persistence.fixOwnership`). The SeaweedFS Deployment now uses the `Recreate` strategy, so S3 is briefly unavailable while it restarts during an upgrade. New `s3.persistence.nfs.mountOptions` for extra NFS mount options on the PV	No – unless you set `s3.persistence.fixOwnership: false`
2.3.6	`s3.volumeMax` and `s3.volumeSizeLimitMB` set the SeaweedFS storage ceiling. The SeaweedFS defaults cap an instance at about 240 GB; installs with a larger dataset must raise `s3.volumeMax`. See capacity planning In practice the default of 8 often caps the bucket at about 31 GB; see 2.4.1.	No – defaults unchanged
2.4.0	Optional MCP server for AI assistants (`mcp.enabled`, default `false`) — see AI Assistants (MCP). Paired readiness/liveness probes on every service, with a 5-minute startup budget on the database-owning services (app, user, licence, notification, events) so boot migrations on a large database are not interrupted	No – but every pod restarts on upgrade to pick up the new probes
2.4.1	SeaweedFS capacity: `s3.volumeMax` defaults to `64` (was `8`), which could leave the `huddo-boards` bucket a single ~31 GB volume. `s3.migration.source.provider` for migrating from Google Cloud Storage	No
2.5.2	Third-party images are pinned to explicit tags: the SeaweedFS helper images `busybox` (`1.38.0`, was untagged) and `amazon/aws-cli` (`2.37.0`), and SeaweedFS moves from `4.17` to `4.47`. The chart no longer sets `s3.imageTag`, so set it in your values file to stay on a specific SeaweedFS version. Includes `2.5.0` and `2.5.1`	No – but the SeaweedFS image changes from `4.17` to `4.47`, so the S3 pod restarts on upgrade (a short gap in S3 availability, as in `2.3.5`)
2.5.3	The SeaweedFS migration Job runs `rclone copy --update` instead of `rclone sync`. It never deletes from SeaweedFS and never replaces a file that the apps changed there, so a Job left enabled after cutover no longer loses data. The finished Job now stays until the next upgrade (was 1 hour), and its report warns only for files missing on SeaweedFS. The `amazon/aws-cli` helper image moves from `2.37.0` to `2.37.4`	No – but files deleted from MinIO during the migration are no longer deleted from SeaweedFS
2.5.4	The deployed resources do not change unless you set `global.podAnnotations.buildNumber`, which the SeaweedFS (`s3`) and MinIO pods now ignore	No
2.6.0	MinIO is pulled from `quay.io/huddo/minio:RELEASE.2022-10-24T18-35-07Z` with your image pull secret (`global.imagePullSecret`) instead of Docker Hub, so the MinIO workaround is no longer needed. `minio.useDockerHub` is removed. `global.ingress.hosts`, `global.ingress.className` (default `cnx-ingress-traefik`) and `global.ingress.tls` set the ingress of every service; a service's own `ingress.hosts`, `ingress.ingressClassName` and `ingress.tls` still win. A service without hosts gets no Ingress. Your own `envArray`, `volumes` and `volumeMounts` now add to the chart defaults instead of replacing them, and `global.envArray` now wins over `global.env`. A service's `image.tag` replaces `global.imageTag` instead of being appended to it (if you set `image.tag` as a suffix, for example `-hotfix`, set the full tag). SeaweedFS moves from `4.47` to `4.48` and `amazon/aws-cli` from `2.37.4` to `2.37.9`. If the copy in the SeaweedFS migration Job fails, the Job still prints its report, which lists the files that did not copy, and then fails. It retries once (was 3 times). On NFS, `helm uninstall` now keeps the SeaweedFS PersistentVolume along with its claim (`s3.persistence.retainOnDelete`, default `true`). Includes `2.5.5`	No – but the MinIO pod restarts (now with the `Recreate` strategy), and the SeaweedFS pod restarts unless you set `s3.imageTag`: a short gap in S3 availability. If your `global.envArray` or a service's `envArray` sets a variable that `global.env` also sets, such as `S3_ACCESS_KEY`, your `envArray` value now applies. Chart defaults that you removed with your own `envArray`, `volumes` or `volumeMounts` come back. See the note under the table

Note

As of huddo-boards-cp 2.3.5 the SeaweedFS pod runs as user 1000 instead of root (the same as the MinIO pods since 1.0.0).

Existing SeaweedFS data is owned by root, and Kubernetes does not apply fsGroup ownership to NFS volumes, so the chart runs a short init container that chowns the data directory to 1000:1000 before SeaweedFS starts. No manual step is required.

If your cluster's Pod Security admission forbids a root container, set s3.persistence.fixOwnership: false and chown the directory yourself on the NFS server instead:

cd /pv-connections/huddo-boards-s3/
chown 1000:1000 -R .

Alternatively set s3.securityContext.enabled: false to keep running as root.

Note

The SeaweedFS pod also moves to the Recreate deployment strategy in 2.3.5. SeaweedFS holds a lock on its storage volume, so the old pod must stop before the new one starts — expect a short gap in S3 availability (and therefore file uploads and downloads) while it restarts during the upgrade.

Upgrading to 2.6.0: MinIO image and environment variables

MinIO. If MinIO is enabled, the chart now pulls quay.io/huddo/minio:RELEASE.2022-10-24T18-35-07Z, the same MinIO version as before, with your image pull secret. The MinIO pod uses the Recreate strategy, so the old pod stops before the new one starts. If the new pod cannot pull the image, MinIO stays down. Before you upgrade, make sure that you can pull the image. If you pull Huddo images from your own registry (global.repository is not quay.io/huddo), copy the image to <global.repository>/minio:RELEASE.2022-10-24T18-35-07Z first. If you applied the MinIO workaround (kubectl set image or kubectl patch), the upgrade replaces it and you do not need to run it again. If you installed the release with Helm 4 and the upgrade stops with conflict with "kubectl-set" or conflict with "kubectl-patch", add --force-conflicts to the helm upgrade command. Remove minio.useDockerHub from your values file: the chart ignores it.

Environment variables. Each variable is now set once, from the first of these that has it:

<service>.env
<service>.envArray
global.envArray
global.env
the chart defaults (the connections-env and huddo-socketcluster-env references)

Before 2.6.0, global.env won over <service>.envArray and global.envArray. The chart's global.env sets S3_ACCESS_KEY, S3_SECRET_KEY, S3_ENDPOINT and S3_BUCKET, among others. If your global.envArray or a service's envArray has an entry with one of these names (for example a Secret reference), the apps now use it instead. Before you upgrade, make sure these entries hold the values you want.

If MinIO is enabled and your global.envArray sets S3_ACCESS_KEY or S3_SECRET_KEY, MinIO also takes its admin user from S3_ACCESS_KEY and its password from S3_SECRET_KEY, and restarts with them. Make sure that the entry holds the key that MinIO uses now. If it holds a different key, change it before you upgrade.

The chart defaults moved to defaultEnvArray, defaultVolumes and defaultVolumeMounts. Your own envArray, volumes and volumeMounts now add to them instead of replacing them. An entry with the same name (or, for volumeMounts, the same mountPath) replaces the default. If you copied the chart defaults into your values file to add an entry, you can remove the copy.

If you set envArray, volumes or volumeMounts to remove the chart defaults from a service, the defaults come back after this upgrade. To remove them now, set defaultEnvArray: [] for that service. To remove the mongo-secret volume, set defaultVolumes: [] and defaultVolumeMounts: [] together. If you clear only defaultVolumes, the upgrade stops with an error.

Upgrade command¶

Log in to our Quay.io registry with the same credentials you use for our images (see the image access guide), then upgrade from the OCI chart:

helm registry login quay.io
helm upgrade huddo-boards-cp oci://quay.io/huddo/huddo-boards-cp --version 2.6.0 -i -f ./boards-cp.yaml --namespace connections

Note

Boards images are date-tagged, so each release changes the global env and pods are recreated automatically on upgrade.

huddo-boards-cp-activity-migration (DEPRECATED)¶

Note

This chart is deprecated as it has been merged into huddo-boards-cp chart as of v2.2.0 as an optional component. Set migration.enabled: true in your values file to enable it.

Before enabling, uninstall any existing standalone release — both create the same PersistentVolume (connections-shared-drive), PersistentVolumeClaim (connections-shared-drive-claim) and Service (boards-activity-migration):

helm uninstall huddo-boards-cp-activity-migration --namespace connections

Version	Description	Breaking Changes
1.0.0	Initial release (Huddo)	No
1.1.0	CNX 8 fix for Mongo 5	No
1.2.0	Fix resource limits	No
1.3.0	Support CNX 8 Mongo 7	No
1.4.0	Support CNX 8 CR13 cache rename - new env variables in ConfigMap and Secret references	No

Standalone Kubernetes¶

Danger

As of huddo-boards 2.0.0 we have migrated from ingress-nginx to Traefik. Please follow our migration guide.

huddo-boards¶

Version	Description	Breaking Changes
1.0.0	Initial release (Huddo)	No
1.1.0	Allow additionalPaths on huddo-app ingress	No
1.1.1	Fix ingress session cookie `SameSite` setting (polling in a CORS frame, e.g. Teams)	No
2.0.0	Move from ingress-nginx to traefik	Yes – migration required
2.1.0	Auto-create secrets: CA bundle mount (`global.internalCa`), `extraObjects`, and `imageCredentials` (image pull secret)	No
2.1.1	Drop legacy support for removed `v1beta1` APIs (Deployment, Ingress)	No
2.1.2	Drop deprecated Traefik `StripPrefix` `forceSlash` option (clears the `ForceSlash` deprecation warning in Traefik logs; no behaviour change)	No
2.1.3	Pod annotations for service mesh injection: `global.podAnnotations` applies to every pod, per-component `podAnnotations` merge on top	No – defaults render unchanged
2.2.0	Optional MCP server for AI assistants (`mcp.enabled`, default `false`) — see AI Assistants (MCP). Paired readiness/liveness probes on every service, with a 5-minute startup budget on the database-owning services (app, user, licence, notification, events) so boot migrations on a large database are not interrupted	No – but every pod restarts on upgrade to pick up the new probes
2.2.1	Repackaged for the Quay.io registry. The deployed resources do not change	No
3.0.2	The Redis image is set with `redis.image` and `redis.imageTag` (defaults `docker.io/redis` and `7-alpine`, the same image as before) instead of `redis.image.repository`. The optional Mixpanel proxy pins `nginx` to `1.31.6-alpine`. Includes `3.0.0` and `3.0.1`	Only if you override the Redis image – an existing `redis.image.repository` override (for example a private mirror) is ignored and the chart pulls `docker.io/redis:7-alpine`. Set `redis.image` and `redis.imageTag` instead, see the warning under the table
3.1.0	The default cache image changes from Redis (`docker.io/redis:7-alpine`) to Valkey (`docker.io/valkey/valkey:9-alpine`), a Redis-compatible server under the BSD-3 licence. The values keys do not change: `redis.image` and `redis.imageTag`	No – the cache pod restarts with an empty cache. If you mirror images or allow only listed images, see the note under the table
3.1.1	The deployed resources do not change unless you set `global.podAnnotations.buildNumber`, which the Valkey cache pod (`redis`) now ignores	No
3.2.0	`global.ingress.hosts`, `global.ingress.className` (default `traefik`) and `global.ingress.tls` set the ingress of every service; a service's own `ingress.hosts`, `ingress.ingressClassName` and `ingress.tls` still win. `core` and `webfront` no longer default to the placeholder hosts `replace.hostname.com` and `default.host.name`, and a service without hosts gets no Ingress. The upgrade stops with an error if `core` and `webfront` have the same host and the same `ingress.path`. The `SOCKET_CLUSTER_*` variables move from `global.envArray` to the chart defaults of each Boards service, so setting your own `global.envArray` no longer removes them. A service's `envArray` and `global.envArray` now win over `global.env`. A service's `image.tag` replaces `global.imageTag` instead of being appended to it (if you set `image.tag` as a suffix, for example `-hotfix`, set the full tag)	No – unless you set the same variable in `global.env` and in `global.envArray` or a service's `envArray`: the `envArray` value now applies. If you set your own `global.envArray`, the `SOCKET_CLUSTER_*` variables come back, so the Boards pods restart. See the note under the table

Upgrading to 3.0.2: Redis image values

The Redis image is now set with redis.image and redis.imageTag. A redis.image.repository override in your values file is ignored, and the chart pulls docker.io/redis:7-alpine instead. If you mirror images (for example in an air-gapped cluster), update your values file before you upgrade:

redis:
  image: my-registry.example.com/redis
  imageTag: "7-alpine"

If you do not override the Redis image, nothing changes.

Upgrading to 3.1.0: Valkey replaces Redis

Huddo Boards uses only standard Redis commands, so Valkey is a drop-in replacement. Redis 7.4 and later use the RSALv2 and SSPLv1 licences, and Redis 8 adds AGPLv3. Many licence policies do not allow these licences. Valkey uses the BSD-3 licence.

The chart does not keep cache data on disk. After the upgrade, the cache starts empty and fills again as people use Boards.

If you mirror images (for example in an air-gapped cluster), do these steps before you upgrade:

Mirror docker.io/valkey/valkey:9-alpine to your registry.

Set both values in your values file:

redis:
  image: my-registry.example.com/valkey/valkey
  imageTag: "9-alpine"

If your values file sets redis.image and redis.imageTag as the 3.0.2 note shows, the chart continues to pull your Redis mirror. Change both values to move to Valkey.

If your values file sets redis.image but not redis.imageTag, the chart asks your mirror for the 9-alpine tag. Set redis.imageTag too: 7-alpine to stay on Redis, or 9-alpine after you mirror Valkey.

If your cluster allows only listed images (for example with an admission policy), add docker.io/valkey/valkey to the list.

Huddo Boards for Component Pack uses the Redis that Component Pack supplies. This change does not apply to it.

Upgrading to 3.2.0: environment variable precedence

Each variable is now set once, from the first of these that has it:

<service>.env
<service>.envArray
global.envArray
global.env
the chart defaults (defaultEnvArray: the SOCKET_CLUSTER_* references)

Before 3.2.0, global.env won over <service>.envArray and global.envArray. If you set the same variable in global.env and in an envArray (for example a Secret reference), the envArray value now applies. Before you upgrade, remove the value you do not want.

If you do not set the same variable twice, nothing changes.

Upgrade command¶

Log in to our Quay.io registry with the same credentials you use for our images (see the image access guide), then upgrade from the OCI chart:

helm registry login quay.io
helm upgrade huddo-boards oci://quay.io/huddo/huddo-boards --version 3.2.0 -i -f ./boards.yaml --namespace boards

Note

Boards images are date-tagged, so each release changes the global env and pods are recreated automatically on upgrade.

huddo-boards-activity-migration¶

Version	Description	Breaking Changes
1.0.0	Initial release (Huddo)	No
1.2.0	Fix resource limits	No
1.2.1	Drop legacy support for removed `v1beta1` Deployment API	No

Info

The previous chart information has moved here