Release Notes
| For chart versions and deployment changes, see the ERS Helm release notes. |
Version 1.1.0
Date: 2026-10-24
| There is no update path from 1.0.4 to 1.1.0 because this release introduces Secure Boot requirements. |
This release runs Management in a single container, introduces one update bundle per target release, and updates the Appliance platform to Talos Linux 1.14. It adds Secure Boot and TPM-backed disk encryption requirements, workload and network restrictions, SSH access configured through the Management host console, and diagnostics for early installation failures.
Management and bundle handling
-
Management runs as one container containing the browser application, backend, Git service and administrative tools. The nested Kubernetes runtime is removed. The container uses a read-only root filesystem, persistent storage at
/var, and temporary filesystems for runtime data. -
Release and update bundles require an exact Management version and build ID. Installation, recovery and update check that the matching build is active.
-
On supported ISO hosts, when a selected bundle requires a newer Management build, Management can prepare its replacement before the appliance operation. Acquiring a bundle alone does not restart Management. Finish active operations and bundle transfers before replacement, then sign in again and restore temporary cluster access.
-
The Management ISO can retain a selected bundle image across reboots and ISO replacement. A failed startup does not automatically roll back the image selection.
-
Each target release has one update bundle, with a declared minimum source version.
Use the Compose configuration supplied with the selected Management release for container deployments.
Keep the persistent /var volume and protect the externally retained recovery files.
Platform changes
The following table compares component versions in 1.0.4 and 1.1.0.
| Component | 1.0.4 | 1.1.0 |
|---|---|---|
Talos Linux |
1.13.10 |
1.14.4 |
Kubernetes |
1.36.4 |
1.36.5 |
etcd |
3.6.14 |
3.7.2 |
Cilium |
1.20.1 |
1.20.3 |
cert-manager |
1.21.1 |
1.21.2 |
Flux CLI |
2.9.5 |
2.9.6 |
Prometheus |
3.14.0 |
3.15.0 |
Prometheus Operator |
0.93.1 |
0.94.1 |
Alertmanager |
0.34.0 |
0.34.1 |
Grafana |
13.2.1 |
13.2.4 |
Loki |
3.7.7 |
3.7.8 |
kube-prometheus-stack chart |
90.0.0 |
92.10.1 |
Loki chart |
18.12.1 |
18.17.0 |
QEMU guest agent |
11.0.2 |
11.1.1 |
VMware guest agent |
1.5.0 |
1.5.1 |
Zot service component |
0.3.0-v1.13 |
0.4.2-v1.14 |
Management host, Fedora CoreOS |
44.20260720.3.1 |
44.20260928.3.1 |
ERS Helm remains at 3.0.0-rc.3, CARA at 3.7.0, CLM and RIS at 6.16.0, and PKCS#11 Network Bridge at 1.0.0. MariaDB remains at 11.4.13, Garage at 2.4.1, and Keycloak at 26.8.0.
Boot, storage and workload security
-
Appliance installation requires signed release media, UEFI Secure Boot and a persistent TPM 2.0 on every node. Installation and update checks verify the required boot security state. Conversion of existing unsecured appliance installations and signing-key rotation are unsupported.
-
Talos system state, ephemeral storage, and the dedicated Database and Data volumes use LUKS2 encryption with TPM-protected keys. Preserve each node’s TPM and firmware state with its installed disks. Recovery onto replacement hardware uses the protected recovery set and enrolls the destination’s own TPM. These controls apply to appliance nodes; the Management ISO state disk remains unencrypted.
-
Zot and hypervisor guest agents run as Talos container services instead of system extensions.
-
Restricted Pod Security admission applies to ordinary appliance workloads. Infrastructure exceptions have explicit admission controls, and local storage provisioning restricts privileged helper pods. Workloads receive narrower privileges, service-account access and writable paths.
-
Cilium policies deny Pod traffic by default and allow the declared application, storage, monitoring and bootstrap connections. Node firewall rules restrict administrative and internal service access. Selected ERS services, Grafana and Alertmanager retain external connectivity for their integrations. Backup export and customer log export receive destination rules from their saved configuration.
-
Node telemetry uses authenticated TLS paths through Alloy. API-server connections to kubelets explicitly validate the kubelet server certificate. Cilium WireGuard protects supported cross-node Pod traffic; these controls do not encrypt every node-network connection.
-
Appliance-node Zot HTTPS moves from TCP 443 to TCP 5443. Installation, HSM library publication and temporary API-lease capture use the new port. Backup capture also understands the Talos 1.14 network configuration format.
Review the hardening guide and the deployment’s firewall rules before installation. The CIS Talos assessment records deviations for combined control-plane and application nodes, reverse-path filtering, and the use of Cilium WireGuard and service TLS in place of KubeSpan. Full CIS Level 1 or Level 2 compliance is not claimed.
Management host access
-
SSH defaults to disabled, with no factory host password.
-
Host access in the console configures passwords, public keys, authentication method and SSH enablement during setup, normal operation and recovery.
-
Access configured before initialization expires at reboot. Access configured after initialization persists across reboots and ISO updates.
-
Unattended Management initialization can explicitly enable SSH and stage a separate host password or public keys from protected files. Supplying keys alone does not enable SSH.
-
Host-access state conversion closes SSH and removes the old host password while preserving host identity, host keys and saved public keys. Have console access before replacing predecessor media, and explicitly configure and enable SSH if needed. This conversion does not establish compatibility with predecessor Management application state.
Installation and diagnostics
-
Disk admission accepts an 80 GiB OS disk, 10 GiB Database disk and 10 GiB Data disk per appliance node, with a 50 GiB Management state disk. Recommended appliance sizing remains 8 vCPUs, 32 GiB RAM and 135/200/500 GiB disks. Minimum capacity does not establish a workload or retention guarantee. See Hardware requirements.
-
Management state initialization tests sequential read/write and mixed random I/O after destructive confirmation. Results below 40 MiB/s for either sequential direction, below 50 aggregate 4 KiB mixed IOPS, or unavailable measurements require explicit acceptance of unsupported performance. Rejecting the result does not restore data overwritten by the test.
-
The VMware Metal OVA supplies the recommended CPU, memory and three-disk layout. Its populated system disk is the OS installation target; Database and Data disks are blank. Signed OVA deployment requires vCenter, a key provider and a fresh vTPM.
-
Installation reuses a verified installed Talos disk boot where possible and wipes the confirmed data disks before provisioning their encrypted volumes. Failed and cancelled installation attempts retain early diagnostic snapshots across retries, including failures before a final artifact bundle exists. Snapshots expire after six hours by default or when Management restarts; download them promptly.
-
The browser terminal is embedded in Management with explicit session controls. Closing a session or leaving its page ends that tab’s root shell; other terminal sessions remain independent.
-
Container deployments can change the Management hostname after initialization while retaining the Git user, repositories and automation identity. Hostname inputs are normalized, and proxy Host forwarding to Headlamp is corrected.
-
ERS setup validates CA lifetimes before submission. Garage initialization uses a dedicated packaged Python runtime rather than monitoring-sidecar tools. Bundle downloads retain a known total size when later progress events omit it. Update completion waits for the published configuration and observed Kubernetes convergence.
Update paths and requirements
There is no update path from 1.0.4 to 1.1.0 because this release introduces Secure Boot requirements. Follow the installation guide for a new deployment.
Version 1.0.4
Date: 2026-10-09
Published to the stable catalog, including Management 1.0.4 and its ISO.
This release updates ERS Helm from 3.0.0-rc.2 to 3.0.0-rc.3 and supplies the exact update bundle from 1.0.3 to 1.0.4.
Nitrokey HSM bridge readiness
The TCP forwarding container reports ready only when both the PKCS#11 Unix socket and the TCP listener are available. This prevents a listening TCP port from reporting readiness while the PKCS#11 backend is unavailable.
ERS workload images, Talos Linux and Kubernetes are unchanged from 1.0.3. PKCS#11 Network Bridge remains at 1.0.0.
Update from 1.0.3
The update requires Management 1.0.2 or later and a maintenance window for single-node and clustered installations. It packages the changed ERS chart without an HSM conversion or platform upgrade. Operations loads the offline content, publishes the target release declarations while preserving operator configuration, and waits for configuration and workload convergence.
Follow the update procedure and retain the verified source recovery set with its matching release bundle. Backups taken before the update require 1.0.3 release content; backups taken after the update require 1.0.4 release content. An interrupted script or failed publication requires explicit Retry.
Version 1.0.3
Date: 2026-10-08
Published to the stable catalog, including Management 1.0.3 and its ISO.
This release corrects the conflicting CARA Prometheus settings in ERS Helm 3.0.0-rc.1 that prevented ERS setup from completing. It also supplies direct update bundles from 1.0.1 and 1.0.2 to 1.0.3.
ERS fix
| Component | 1.0.2 | 1.0.3 |
|---|---|---|
ERS Helm chart |
3.0.0-rc.1 |
3.0.0-rc.2 |
ERS workload images, Talos Linux and Kubernetes are unchanged from 1.0.2. CARA remains at 3.7.0, and CLM and RIS remain at 6.16.0.
Update paths and requirements
Both update paths require Management 1.0.2 or later and a maintenance window for single-node and clustered installations. There is no direct 1.0.0-to-1.0.3 update bundle.
-
From 1.0.2, the update replaces the ERS chart with 3.0.0-rc.2. It performs no HSM conversion or platform upgrade.
-
From 1.0.1, the update includes the changed ERS workload images and converts generated software, Utimaco and Securosys HSM settings to the ERS Helm 3 format. It preserves uploaded HSM image identities, credentials and unrelated operator settings. Custom HSM mounts or environment settings require review; historical generic library images are unsupported. Talos Linux and Kubernetes are unchanged from 1.0.1.
For an update from 1.0.1, update Management first and complete the appliance update before making other GitOps changes. Management cannot read the old HSM settings until the update converts them.
Follow the update procedure and retain the verified source recovery set with its matching release bundle. Source-backup verification does not rewrite the original backup. Source backups require their original release content; backups taken after the update require 1.0.3 release content. An interrupted script or failed publication requires explicit Retry.
Version 1.0.2
Date: 2026-10-07
This release introduces ERS Helm 3, Nitrokey HSM2 configuration and improvements to bundle uploads and platform reconciliation. The Appliance update is the exact transition from 1.0.1 to 1.0.2 and requires Management 1.0.2.
ERS and HSM changes
| Component | 1.0.1 | 1.0.2 |
|---|---|---|
ERS Helm chart |
2.1.0 |
3.0.0-rc.1 |
CARA |
3.6.0 |
3.7.0 |
CLM and RIS |
6.15.0 |
6.16.0 |
Management adds a Nitrokey option for an initialized Nitrokey HSM2, with a token serial and the appliance node to which the USB device is attached. All CARA replicas use the token on the selected node. Loss of that node or token interrupts HSM access, including on a three-node appliance.
Management improvements
-
Bundle uploads can run concurrently without disabling unrelated bundle actions. Each upload retains its own progress and cancellation controls.
-
Failed archive uploads display a request ID when the server supplies one, so the failure can be matched to diagnostics.
-
Management detects the previous ERS HSM configuration format and directs the operator to complete the appliance update before editing ERS settings.
Platform changes
-
Flux installs and maintains Kubernetes add-ons after networking and DNS bootstrap, including storage, certificate management and gateway components. Operator charts wait for their selected CRDs before advancing.
-
Database and namespace reconciliation retains state during ordinary GitOps removal. This does not protect against privileged direct deletion or replace backups.
-
Gateway rollouts create a replacement before removing the existing local endpoint.
-
Prometheus uses process signals to reload configuration and has a 120-second shutdown grace period.
Update requirements
Both single-node and clustered installations require a maintenance window for this update. There is no direct 1.0.0-to-1.0.2 update bundle.
Update Management to 1.0.2, then complete the appliance update before making other GitOps changes. Until the update converts the HSM values, Management cannot read the old ERS settings and Operations rejects ordinary GitOps publication. The update’s own publication runs after conversion.
Follow the update procedure and preserve the verified source recovery set. The update verifies the original 1.0.1 backup without rewriting it. Source backups remain recoverable with 1.0.1 release content; target backups require 1.0.2 release content. Keep both recovery sets with their matching release bundles.
The update loads changed offline content, replaces vendor declarations while retaining installation settings, and waits for the published configuration and workloads to converge. It retains explicit Retry for interrupted scripts or publication failures.
Version 1.0.1
Date: 2026-10-04
Published to the stable catalog.
This release refreshes the appliance platform and supplies the first published update bundle, for the exact transition from 1.0.0 to 1.0.1.
The minimum Management version remains 1.0.0.
Platform changes
The following table lists selected version changes. The versioned release inputs record the complete image and chart selections with their checksums and digests.
| Component | 1.0.0 | 1.0.1 |
|---|---|---|
Talos Linux |
1.13.7 |
1.13.10 |
Kubernetes |
1.36.3 |
1.36.4 |
CoreDNS |
1.14.4 |
1.14.7 |
etcd |
3.6.12 |
3.6.14 |
Cilium |
1.20.0 |
1.20.1 |
Gateway API |
1.5.1 |
1.6.2 |
NGINX Gateway Fabric |
2.6.7 |
2.7.0 |
cert-manager |
1.21.0 |
1.21.1 |
Garage |
2.3.0 |
2.4.1 |
MariaDB |
11.4.12 |
11.4.13 |
Prometheus |
3.13.1 |
3.14.0 |
Grafana |
13.1.1 |
13.2.1, distroless image |
Loki |
3.7.4 |
3.7.7 |
Alloy |
1.18.0 |
1.19.2 |
Mimir |
3.1.4 |
3.2.0 |
The ERS chart remains at 2.1.0, CARA at 3.6.0, CLM at 6.15.0 and Keycloak at 26.7.3.
Update from 1.0.0
The update bundle supplies the changed offline images and charts, including the matching Talos installers. Its numbered scripts update the platform, publish the target configuration, and verify component readiness before recording appliance version 1.0.1. The update preserves installation settings and selects the installer for the existing agentless, QEMU-agent or VMware-agent profile. Secure Boot configurations are outside this update’s supported installer profiles.
Follow the update procedure with Management 1.0.0 or a version explicitly qualified for this appliance. Keep the exact source recovery set outside Management and acknowledge it before applying the update. An interrupted script or failed publication requires explicit Retry. After completion, retain the new target backup and verify ERS access.
Single-node installations require maintenance. The published bundle declares that maintenance is not required for clustered installations.
Use the 1.0.1 release bundle for a fresh installation or recovery of a matching backup. A release bundle cannot replace the 1.0.0-to-1.0.1 update bundle.
Version 1.0.0
Date: 2026-09-15
First Release Scope
-
A separate Management VM boots from the Management ISO and keeps host and Management state on its dedicated disk.
-
Management also runs with Docker or Docker Compose on an operator workstation or an operator-created Linux VM. Operators supply and maintain the host, container runtime, networking, TLS and persistent storage.
-
Management installs the Appliance from supplied release content and provides configuration, reconnection, ERS setup, HSM library administration, monitoring access and diagnostics.
-
Appliance backup configuration, completed-backup downloads, external publication and full recovery have dedicated operator workflows.
-
Release, update, artifact, backup, recovery and diagnostics bundles have distinct purposes and retention requirements.
Deploy Management using the Management ISO or Docker Compose, then follow Appliance Installation and Verification.
Operator Actions
In this original release, Management ISO deployments enabled SSH with factory credentials for initial setup. Those ISOs require restricted maintenance-network access and the release-specific persistent credential-rotation procedure before production use. Newer ISO access controls change this default. Follow the migration guidance when moving from an older ISO.
Retain the downloaded artifact bundle outside Management. Set up backups and protected external retention, record the deployed component identities and verify application access after ERS setup.
Management access is temporary. Keep the artifact bundle available for reconnection after access expiry or Management restart. Management loss and Appliance loss use different recovery paths.
Compatibility and Update Paths
There is no upgrade path from an earlier released Virtual Appliance version because 1.0.0 is the first release. Migration from development media or state is not supported.
Use the supplied 1.0.0 release material to identify compatible Management media and embedded component versions. See components and version records. Full recovery requires the release bundle that matches the backed-up Appliance release, together with its matching artifacts and compatible Management.
Operational Limits
-
The Management ISO remains attached and boots the host on every start. The state disk does not contain an installed host operating system.
-
The ISO provides no rollback workflow, Management password reset, or Management state-disk restore tool. Reconstruct Management for a surviving Appliance with retained artifacts.
-
Full backups exclude metrics history, log history and Grafana’s local database and UI-created state. External HSM keys need separate protection.
-
Saving and publishing configuration do not confirm that workloads are healthy. Verify the affected service after changes.
-
Diagnostics retains only the latest temporary result. Download it before another collection or Management restart.
-
This manual does not define an individual-node replacement procedure. Contact support for that failure scenario.