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 from Quay.io, the ingress set once in global.ingress and a new environment variable order. See What changed in 2.6.0. Includes 2.5.5	No – but the MinIO and SeaweedFS pods restart, and an envArray value now wins over global.env. See the notes below
3.0.1	No default S3 keys, TLS certificate checks, Boards prefix stripping and ClusterIP Services. See What changed in 3.0.1. Includes 3.0.0	Yes – set the S3 keys first, and global.internalCa if you use a private CA. See the warning below

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.

What changed in 2.6.0

• MinIO: 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.
• Ingress: 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.
• Environment variables: your own envArray, volumes and volumeMounts now add to the chart defaults instead of replacing them, and global.envArray now wins over global.env. 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.
• Image tags: 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 migration Job: 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).
• NFS: helm uninstall now keeps the SeaweedFS PersistentVolume along with its claim (s3.persistence.retainOnDelete, default true).
• Images: SeaweedFS moves from 4.47 to 4.48 and amazon/aws-cli from 2.37.4 to 2.37.9.
• Restarts: 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.

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:

1. <service>.env
2. <service>.envArray
3. global.envArray
4. global.env
5. 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.

What changed in 3.0.1

• S3 keys: the chart no longer sets them. global.env.S3_ACCESS_KEY and global.env.S3_SECRET_KEY have no default, and SeaweedFS now takes the same keys as MinIO and the apps, from global.envArray or global.env. s3.accessKey and s3.secretKey are now empty, and s3.secretKeyRef.name no longer defaults to s3-secret.
• TLS: core, user and provider no longer set NODE_TLS_REJECT_UNAUTHORIZED: '0', so they check TLS certificates. If Connections, MongoDB or S3 uses a private CA or a self-signed certificate, Boards calls to it fail until you set global.internalCa.
• Boards ingress: core and webfront strip /api-boards and /boards by default (ingress.traefik.stripPrefix.enabled: true), as the Traefik guide sets.
• Services: the core and webfront Services, and any other Service you enabled (including the activity migration), change from NodePort to ClusterIP. To keep a node port, set <service>.service.type: NodePort.
• Ingress annotations: your own traefik.ingress.kubernetes.io/router.middlewares annotation in ingress.annotations is now added after the chart's middlewares, instead of one replacing the other.
• Image pull secret: the upgrade stops with an error if imageCredentials.username or imageCredentials.password is not a string.
• Internal CA: the Secret that global.internalCa.pem creates is kept on helm uninstall.
• Images: the amazon/aws-cli helper image moves from 2.37.9 to 2.38.1.
• Restarts: the core, user and provider pods restart. If you set new S3 keys or take them from a Secret, every Boards pod, MinIO and SeaweedFS restart too.

Before you upgrade to 3.0.1

• If your values file does not set global.env.S3_ACCESS_KEY and global.env.S3_SECRET_KEY, your release uses the keys that the chart set before. These keys were published in the chart. Set the keys in global.env, or take them from a Secret with global.envArray entries of the same names. To keep the same keys, copy them from helm get values huddo-boards-cp --all --namespace connections. If you set new keys, every pod that uses S3 restarts; SeaweedFS reads its keys each time it starts, so new keys work with its existing files. MinIO (minio) and SeaweedFS (s3) use the same keys as the apps. Without the keys, the upgrade stops with an error and the running release does not change.
• If you take the SeaweedFS secret key from a Secret with s3.secretKeyRef, set s3.secretKeyRef.name. It no longer defaults to s3-secret. Without a name, SeaweedFS uses S3_SECRET_KEY from global.envArray or global.env, with no error.
• If Connections, MongoDB or S3 presents a certificate from a private CA or a self-signed certificate, set global.internalCa as described in SSL. core, user and provider no longer set NODE_TLS_REJECT_UNAUTHORIZED: '0'. If you do not, the upgrade succeeds, but login, profile and community lookups and Boards calls to Connections fail, and the pod logs show SELF_SIGNED_CERT_IN_CHAIN or UNABLE_TO_VERIFY_LEAF_SIGNATURE.
• If your ingress controller is not Traefik, set core.ingress.traefik.stripPrefix.enabled: false and webfront.ingress.traefik.stripPrefix.enabled: false. These services now create a Traefik Middleware when they have an ingress host. Without the Traefik CRDs, the upgrade fails.
• If something reaches a Boards service on a node port, set service.type: NodePort on that service, for example webfront.service.type: NodePort. This includes an ingress controller or load balancer that sends traffic to node ports. The core and webfront Services, and any other Service you enabled, are now ClusterIP, so the upgrade removes their node ports, and the upgrade does not detect this. If you set service.nodePort without service.type: NodePort (or LoadBalancer), the upgrade stops with an error.
• If you set imageCredentials, quote username and password as strings (or use --set-string). An unquoted number now stops the upgrade 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 3.0.1 -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	The ingress set once in global.ingress, no placeholder hosts and a new environment variable order. See What changed in 3.2.0	No – unless you set the same variable in global.env and in an envArray. See the notes below
3.3.1	ClusterIP Services and a Mixpanel proxy image update. See What changed in 3.3.1. Includes 3.3.0	Only if you reach a service on a node port. See the warning below

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:

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

2. 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.

What changed in 3.2.0

• Ingress: 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.
• Environment variables: 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: if you set the same variable in global.env and in global.envArray or a service's envArray, the envArray value now applies.
• Image tags: 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.
• Restarts: if you set your own global.envArray, the SOCKET_CLUSTER_* variables come back, so the Boards pods restart.

Upgrading to 3.2.0: environment variable precedence

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

1. <service>.env
2. <service>.envArray
3. global.envArray
4. global.env
5. 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.

What changed in 3.3.1

• Services: the core, webfront and optional Mixpanel proxy Services, and any other Service you enabled, change from NodePort to ClusterIP. To keep a node port, set <service>.service.type: NodePort.
• Mixpanel proxy: nginx moves from 1.31.6-alpine to 1.31.8-alpine.
• Ingress annotations: your own traefik.ingress.kubernetes.io/router.middlewares annotation in ingress.annotations is now added after the chart's middlewares, instead of one replacing the other.
• Image pull secret: the upgrade stops with an error if imageCredentials.username or imageCredentials.password is not a string.
• Internal CA: the Secret that global.internalCa.pem creates is kept on helm uninstall.
• Restarts: the Mixpanel proxy pod restarts if you enabled it.

Before you upgrade to 3.3.1

• If something reaches a Boards service on a node port, set service.type: NodePort on that service, for example webfront.service.type: NodePort or mixpanel-proxy.service.type: NodePort. This includes an ingress controller or load balancer that sends traffic to node ports. The core, webfront and Mixpanel proxy Services, and any other Service you enabled, are now ClusterIP, so the upgrade removes their node ports, and the upgrade does not detect this. If you set service.nodePort on core, webfront or another Boards service without service.type: NodePort (or LoadBalancer), the upgrade stops with an error and the running release does not change.
• If you set imageCredentials, quote username and password as strings (or use --set-string). An unquoted number now stops the upgrade 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 oci://quay.io/huddo/huddo-boards --version 3.3.1 -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