Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.siderolabs.com/llms.txt

Use this file to discover all available pages before exploring further.

​
v1.13.0
Talos
Release notes →

​
Clang built kernel and ThinLTO

Talos now uses a kernel built using Clang compiler, and optimized using ThinLTO. This should bring a small performance improvement, alongside some hardening features, such as BTI on supported ARM systems.

​
Container Device Interface

Talos now enables CDI by default and extension/extension services can bring in dynamic CDI spec files under /run/cdi.

​
talosctl debug

Talos Linux now provides a way to run and attach to the privileged debug container with a user-provided container image. The debug container might be used for troubleshooting and debugging purposes.

​
Environment Configuration Document

A new EnvironmentConfig document has been introduced to allow users to specify environment variables for Talos components. It replaces and deprecates the previous method of setting environment variables via the .machine.env field.Multiple values for the same environment variable will replace previous values, with the last one taking precedence.To remove an environment variable, remove it from the EnvironmentConfig document and restart the node.

​
External Volumes

Talos now supports virtiofs-based external volumes via the new ExternalVolumeConfig document.These virtiofs external volumes are not supported when SELinux is running in enforcing mode.

​
Extra Arguments accept slices in addition to strings

Several Talos configuration fields that previously accepted single string values for extra arguments have been updated to accept slices of strings as well. This includes fields such as .cluster.apiServer.extraArgs.BREAKING: If you were relying on the resources EtcdConfigs, KubeletConfigs, ControllerManagerConfigs, SchedulerConfigs or APIServerConfigs, the protobuf format has changed from map<string,string> to map<string,message>.

​
Container Image Signature Verification

Talos now supports machine-wide container image signature verification via the new ImageVerificationConfig machine config document.Any image which gets pulled on the node will be verified against the configured rules, and if no rule matches, it will be pulled without verification.

​
Talos Imager Enhancements

Talos imager now supports running rootless. --privileged and -v /dev:/dev are no longer required.

​
Image APIs Updated

Talos Linux provides new APIs to manage container images on the node: listing, pulling, importing and removing images. The new pull API provides pull progress notifications.The CLI commands talosctl image pull, talosctl image list and talosctl image remove have been updated to interact with the new APIs.

​
Talosctl images k8s-bundle subcommand accepts version parameter

The talosctl images k8s-bundle command now accepts an optional argument to override Talos version.

​
Install and Upgrade API

Talos now exposes install and upgrade operations via the LifecycleService API, enabling programmatic installs and upgrades through a single, consistent interface. The legacy upgrade API is deprecated; new integrations should migrate to LifecycleService for future compatibility.

​
Kubernetes server-side apply

Talos now uses inventory backed server-side apply when applying bootstrap manifests (including extraManifests and inlineManifests). Purging of unneeded manifests is automatically performed. The switch and inventory backfill is automatic and no action is needed from the user.

​
Dynamic Linux Kernel Preemption Model

Talos Linux now defaults to dynamic Linux kernel preemption model, the default value none matches previous version, but now with kernel argument preempt= the preemption model can be changed.See Linux kernel documentation for more information on supported values.This change only applies to amd64 (x86_64) architecture.

​
KubeSpan Configuration

A new KubeSpanConfig document has been introduced to configure KubeSpan settings. It replaces and deprecates the previous method of configuring KubeSpan via the .machine.network.kubespan field.The old configuration field will continue to work for backward compatibility.

​
KubeSpan Advertised Network Filters

KubeSpan now supports filtering of advertised networks using the excludeAdvertisedNetworks field in the KubeSpanConfig document. This allows users to specify a list of CIDRs to exclude from the advertised networks. Please note that routing must be symmetric for any pair of peers, so if one peer excludes a certain network, the other peer must also exclude it. In other words, for any given pair of peers, and any pair of their addresses, the traffic should either go through KubeSpan or not, but not one way or the other.

​
LinkAliasConfig Pattern-Based Multi-Alias

LinkAliasConfig now supports pattern-based alias names using %d format verb (e.g. net%d).When the alias name contains a %d format verb, the selector is allowed to match multiple links. Each matched link receives a sequential alias (e.g. net0, net1, …) based on hardware address order of the links. Links already aliased by a previous config are automatically skipped.This enables creating stable aliases from any N links using a single config document, useful for BondConfig and BridgeConfig member interfaces on varying hardware.

​
Negative Max Volume Size

Negative max size represents the amount of space to be left free on the device, rather than the size the volume should consume. For example:
  • a max size of “-10GiB” means the volume can grow to the available space minus 10GiB.
  • a max size of “-25%” means the volume can grow to the available space minus 25%.

​
Flannel CNI with Network Policy Support

Talos Linux now supports optionally deploying Flannel CNI with network policy support enabled. The network policy implementation is kube-network-policies.To enable Flannel CNI with network policy support, use the following machine configuration patch:
cluster:
  network:
    cni:
      name: flannel
      flannel:
        kubeNetworkPoliciesEnabled: true
(If the cluster is already running, sync the bootstrap manifests after applying the patch to deploy the new CNI configuration.)

​
NVIDIA GPU Support

Talos switched to using CDI and now supports configuring NVIDIA GPU via the gpu-operator helm chart. See the documentation on upgrade notes for more details on how to configure NVIDIA GPU support in Talos.

​
Container Image Decompression

Talos now ships with igzip (amd64) and pigz (arm64) to speed up container image decompression.

​
ProbeConfig

The TCPProbeConfig configuration document allows to configure TCP probes for network reachability checks. This allows to define a custom connectivity condition.

​
/proc/PID/mem Access Hardening

A new kernel parameter proc_mem.force_override=never has been introduced by default to enhance system security by preventing unwanted writes to protected process memory via /proc/PID/mem. If the kernel parameter is removed, default behavior is restored, allowing access only if the process is traced.

​
Reproducible Disk Images

Talos disk images are now reproducible. Building the same version of Talos multiple times will yield identical disk images.Note: VHD and VMDK (Azure and VMware) images are not currently reproducible due to limitations in the underlying image creation tools. Users verifying reproducible images should use raw images, verify checksums, and convert them to VHD/VMDK as needed.

​
ResolverConfig

The nameservers configuration in machine configuration now overwrites any previous layers (defaults, platform, etc.) when specified. Previously a smart merge was performed to keep IPv4/IPv6 nameservers from lower layers if the machine configuration specified only one type.

​
Routing Rules Support

Talos now supports routing rules via the new RoutingRuleConfig machine config document.

​
talosctl images talos-bundle can ignore reaching to the registry

The talosctl images talos-bundle command now accepts optional --overlays and --extensions flags. If those are set to false, the command will not attempt to reach out to the container registry to fetch the latest versions and digests of the overlays and extensions.

​
Lifecycle Upgrade in talosctl

talosctl upgrades now route through LifecycleService, aligning CLI behavior with the new install/upgrade API and unifying the upgrade path. This change is transparent to users but standardizes the backend used for upgrades.

​
Component Updates

Linux: 6.18.24 containerd: 2.2.3 etcd: 3.6.9 CoreDNS: 1.14.2 Kubernetes: 1.36.0 CNI: 1.9.1 Flannel CNI plugin: v1.9.1-flannel1 Flannel: 0.28.4 LVM2: 2_03_38 runc: 1.4.2 systemd: 259.5 cryptsetup: 2.8.3 Tenstorrent: 2.7.0 iptables: 1.8.12 musl: 1.2.6Talos is built with Go 1.26.2.

​
VM Hot-Add Support

Talos now includes udev rules to support hot-adding of CPUs in virtualized environments.

​
VRF Support

Talos now supports VRF (Virtual Routing and Forwarding) via the new VRFConfig machine config document.
​
v1.12.7
Talos
Release notes →

​
Component Updates

Linux: 6.18.24 containerd: 2.1.7 etcd: 3.6.9 Kubernetes: v1.35.4Talos is built with Go 1.25.9.
​
v1.12.6
Talos
Release notes →

​
Component Updates

Linux: 6.18.18 runc: 1.3.5Talos is built with Go 1.25.8.
​
v1.12.5
Talos
Release notes →

​
Component Updates

Linux: 6.18.15 Kubernetes: 1.35.2 etcd: 3.6.8Talos is built with Go 1.25.8.
​
v1.12.4
Talos
Release notes →

​
KubeSpan Advertised Network Filters

KubeSpan now supports filtering of advertised networks using the excludeAdvertisedNetworks field in the KubeSpanConfig document. This allows users to specify a list of CIDRs to exclude from the advertised networks. Please note that routing must be symmetric for any pair of peers, so if one peer excludes a certain network, the other peer must also exclude it. In other words, for any given pair of peers, and any pair of their addresses, the traffic should either go through KubeSpan or not, but not one way or the other.

​
Component Updates

Linux: 6.18.9Talos is built with Go 1.25.7.
​
v1.12.3
Talos
Release notes →

​
Component Updates

Linux: 6.18.8Talos is built with Go 1.25.7.
​
v1.12.2
Talos
Release notes →

​
talosctl images talos-bundle can ignore reaching to the registry

The talosctl images talos-bundle command now accepts optional --ovelays and --extensions flags. If those are set to false, the command will not attempt to reach out to the container registry to fetch the latest versions and digests of the overlays and extensions.

​
Component Updates

Linux: 6.18.5Talos is built with Go 1.25.6.
​
v1.12.1
Talos
Release notes →

​
Component Updates

Linux: 6.18.2Talos is built with Go 1.25.5.
​
v1.12.0
Talos
Release notes →

​
What’s New

See also What’s new in Talos v1.12.0 in the documentation for a summary of the most notable changes in this release.

​
API Server Cipher Suites

The Kubernetes API server in Talos has been updated to use a more secure set of TLS cipher suites by default. This is in line with a set of best practices documented in CIS 1.12 benchmark.You can still expand the list of supported cipher suites via the cluster.apiServer.extraArgs."tls-cipher-suites" machine configuration field if needed.

​
New User Volume type - bind

New field in UserVolumeConfig - volumeType that defaults to partition, but can be set to directory. When set to directory, provisioning and filesystem operations are skipped and a directory is created under /var/mnt/<name>.The directory type enables lightweight storage volumes backed by a host directory, instead of requiring a full block device partition.When volumeType = "directory":
  • A directory is created at /var/mnt/<metadata.name>;
  • provisioning, filesystem and encryption are prohibited.
Note: this mode does not provide filesystem-level isolation and inherits the EPHEMERAL partition capacity limits. It should not be used for workloads requiring predictable storage quotas.

​
Disk Encryption

Talos versions prior to v1.12 used the state of PCR 7 and signed policies locked to PCR 11 for TPM based disk encryption.Talos now supports configuring which PCRs states are to be used for TPM based disk encryption via the options.pcrs field in the tpm section of the disk encryption configuration.If user doesn’t specify any options Talos defaults to using PCR 7 for backwards compatibility with existing installations.This change was made to improve compatibility with systems that may have varying states in PCR 7 due to UEFI Secure Boot configurations and users may wish to disable locking to PCR 7 state entirely.Signed PCR policies will still be bound to PCR 11.The currently used PCR’s can be seen with talosctl get volumestatus <volume> -o yaml command.

​
New User Volume type - disk

volumeType in UserVolumeConfig can be set to disk. When set to disk, a full block device is used for the volume.When volumeType = "disk":
  • Size specific settings are not allowed in the provisioning block (minSize, maxSize, grow).

​
Embedded Config

Talos Linux now supports embedding the machine configuration directly into the boot image.

​
etcd

etcd container image is now pulled from registry.k8s.io/etcd instead of gcr.io/etcd-development/etcd.

​
Ethernet Configuration

The Ethernet configuration now includes a wakeOnLAN field to enable Wake-on-LAN (WOL) support. This field can be set to enable WOL and specify the desired WOL modes.

​
Extra Binaries

Talos Linux now ships with nft binary in the rootfs to support CNIs which shell out to nft command.

​
Feature Lock

Talos now ignores the following machine configuration fields:
  • machine.features.rbac (locked to true)
  • machine.features.apidCheckExtKeyUsage (locked to true)
  • cluster.apiServer.disablePodSecurityPolicy (locked to true)
These fields were removed from the default machine configuration schema in v1.12 and are now always set to the locked values above.

​
Talos force reboot

Talos now supports a “force” reboot mode, which allows skipping the graceful userland termination. It can be used in situations where a userland service (e.g. the kubelet) gets stuck during graceful shutdown, causing the regular reboot flow to fail.In addition, talosctl was updated to support this feature via talosctl reboot --mode force.

​
GRUB

Talos Linux introduces new machine configuration option .machine.install.grubUseUKICmdline to control whether GRUB should use the kernel command line provided by the boot assets (UKI) or to use the command line constructed by Talos itself (legacy behavior).This option defaults to true for new installations, which means that GRUB will use the command line from the UKI, making it easier to customize kernel parameters via boot asset generation. For existing installations upgrading to v1.12, this option will default to false to preserve the legacy behavior.

​
Kernel Log

The kernel log (dmesg) is now also available as the service log named kernel (talosctl logs kernel).

​
Kernel Module

Talos now supports optionally disabling kernel module signature verification by setting module.sig_enforce=0 kernel parameter. By default module signature verification is enabled (module.sig_enforce=1). When using Factory or Imager supply as -module.sig_enfore module.sig_enforce=0 kernel parameters to disable module signature enforcement.

​
Kernel Security Posture Profile (KSPP)

Talos now enables a stricter set of KSPP sysctl settings by default. The list of overridden settings is available with talosctl get kernelparamstatus command.

​
Encrypted Volumes

Talos Linux now consistently provides mapped names for encrypted volumes in the format /dev/mapper/luks2-<volume-id>. This change should not affect system or user volumes, but might allow easier identification of encrypted volumes, and specifically for raw encrypted volumes.

​
Network Configuration

The network configuration under .machine.network (with the exception of KubeSpan) has been deprecated, but it is still supported for backwards compatibility. See documentation for more information.

​
Persistent logs

Talos now stores system component logs in /var/log, featuring automatic log rotation and keeping two most recent log files. This change allows collecting logs from Talos like on any other Linux system.

​
CRI Registry Configuration

The CRI registry configuration in v1apha1 legacy machine configuration under .machine.registries is now deprecated, but still supported for backwards compatibility. New configuration documents RegistryMirrorConfig, RegistryAuthConfig and RegistryTLSConfig should be used instead.

​
talosctl image cache-serve

talosctl includes new subcommand image cache-serve. It allows serving the created OCI image registry over HTTP/HTTPS. It is a read-only registry, meaning images cannot be pushed to it, but the backing storage can be updated by re-running the cache-create command;Additionally talosctl image cache-create has some changes:
  • new flag --layout: oci (default), flat:
    • oci preserves current behavior;
    • flat does not repack artifact layer, but moves it to a destination directory, allowing it to be served by talosctl image cache-serve;
  • changed flag --platform: now can accept multiple os/arch combinations:
    • comma separated (--platform=linux/amd64,linux/arm64);
    • multiple instances (--platform=linux/amd64 --platform=linux/arm64);

​
UEFI Boot

When using UEFI boot with systemd-boot as bootloader (on new installs of Talos from 1.10+ onwards), Talos will now not touch the UEFI boot order. Talos 1.11 made a fix to create UEFI boot entry and set the boot order as first entry, but this behavior caused issues on some systems. To avoid further issues, Talos will now only create the UEFI boot entry if it does not exist, but will not modify the boot order.

​
Component Updates

Linux: 6.18.1 Kubernetes: 1.35.0 CNI Plugins: 1.9.0 cryptsetup: 2.8.1 LVM2: 2_03_37 systemd-udevd: 257.8 etcd: 3.6.7 CoreDNS: 1.13.2 Flannel: 0.27.4 Flannel CNI plugin: v1.8.0-flannel2 runc: 1.3.4 containerd: 2.1.6 zfs: 2.4.0Talos is built with Go 1.25.5.
​
v1.11.6
Talos
Release notes →

​
UEFI Boot

When using UEFI boot with systemd-boot as bootloader (on new installs of Talos from 1.10+ onwards), Talos will now not touch the UEFI boot order. Talos 1.11 made a fix to create UEFI boot entry and set the boot order as first entry, but this behavior caused issues on some systems. To avoid further issues, Talos will now only create the UEFI boot entry if it does not exist, but will not modify the boot order.

​
Component Updates

Linux: 6.12.62 runc: 1.3.4Talos is built with Go 1.24.11.
​
v1.11.5
Talos
Release notes →

​
Component Updates

containerd: 2.1.5Talos is built with Go 1.24.9.
​
v1.11.4
Talos
Release notes →

​
Component Updates

runc: 1.3.3 Linux: 6.12.57 linux-firmware: 20251021Talos is built with Go 1.24.9.
​
v1.11.3
Talos
Release notes →

​
Component Updates

runc: 1.3.2 Kubernetes: 1.34.1 Linux: 6.12.52 linux-firmware: 20251011 CoreDNS: 1.12.4 etcd: 3.6.5 Flannel: 0.27.4Talos is built with Go 1.24.9.
​
v1.11.2
Talos
Release notes →

​
Component Updates

runc: 1.3.1 Kubernetes: 1.34.1 Linux: 6.12.48 linux-firmware: 20250917Talos is built with Go 1.24.6.
​
v1.11.1
Talos
Release notes →

​
Component Updates

Linux: 6.12.45 CoreDNS: 1.12.3Talos is built with Go 1.24.6.
​
v1.11.0
Talos
Release notes →

​
Azure

Talos on Azure now defaults to MTU of 1400 bytes for the eth0 interface to avoid packet fragmentation issues. The default MTU can be overriden via machine configuration.

​
Boot

Talos boot partition size increased to 2 GiB to accommodate large images (with many system extensions included).

​
Kernel Command Line

Talos now exposes the kernel command line as a KernelCmdline resource (talosctl get cmdline).

​
Disk Encryption

Disk encryption for system volumes is now managed by the VolumeConfig machine configuration document. Legacy configuration in valpha1 machine configuration is still supported.New per-key option lockToSTATE is added to the VolumeConfig document, which allows to lock the volume encryption key to the secret salt in the STATE volume. So, if the STATE volume is wiped or replaced, the volume encryption key will not be usable anymore.

​
Disk Wipe

Talos now supports talosctl disk wipe command in maintenance mode (talosctl disk wipe <disk> --insecure).

​
Early Inline Configuration

Talos now supports passing early inline configuration via the talos.config.early kernel parameter. This allows to pass the configuration before the platform config source is probed, which is useful for early boot configuration. The value of this parameter has the same format as the talos.config.inline parameter, i.e. it should be base64 encoded and zstd-compressed.

​
ETCD downgrade API

Added ETCD downgrade API mimicking the ETCD API and etcdctl interfaces. This API allows to downgrade ETCD cluster (storage format) to a previous version.

​
IMA support removed

Talos now drops the IMA (Integrity Measurement Architecture) support. This feature was not used in Talos for any meaningful security purpose and has historically caused performance issues. See #11133 for more details.

​
Kubernetes Version Validation

Talos now validates the Kubernetes version in the image specified in the machine configuration. Previously this check was performed only on upgrade, but now it is consistently applied to upgrade, initial provisioning, and machine configuration updates.This implies that all image references should contain the tag, even if the image is pinned by digest.

​
Qemu provisioner on MacOS

On MacOS talosctl cluster create command now supports the Qemu provisioner in addition to the Docker provisioner.

​
Kernel Modules

Talosctl now returns the loaded modules, not the modules configured to be loaded (talosctl get modules).

​
SBOM

Talos now publishes Software Bill of Materials (SBOM) in the SPDX format.

​
Swap Suport

Talos now supports swap on block devices. This feature can be enable by using SwapVolumeConfig document in the machine configuration.

​
Component Updates

Linux: 6.12.43 Kubernetes: 1.34.0 runc: 1.3.0 etcd: 3.6.4 containerd: 2.1.4 Flannel CNI plugin: 1.7.1-flannel1 Flannel: 0.27.2 CoreDNS: 1.12.2 xfsprogs: 6.15.0 systemd-udevd and systemd-boot: 257.7 lvm2: 2.03.33 cryptsetup: 2.8.0Talos is built with Go 1.24.6.

​
VMware

Talos VMWare platform now supports arm64 architecture in addition to amd64.

​
Volumes

Talos now supports raw user volumes, allowing to allocate unformatted disk space as partition. In addition to that, support for existing volumes has been added, allowing to mount existing partitions without formatting them.

​
Zswap Support

Talos now supports zswap, a compressed cache for swap pages. This feature can be enabled by using ZswapConfig document in the machine configuration.
​
v1.10.9
Talos
Release notes →

​
etcd Zombine Members

See this blog post for more details.This release includes an update to etcd v3.5.26 to ensure that upgrades to Talos v1.11 and later (which default to etcd v3.6) will not be blocked by the presence of zombine members in the etcd cluster.Please note that etcd version can also be configured via the machine configuration with any version of Talos Linux.

​
Component Updates

Linux: 6.12.63 runc: 1.2.9 etcd: 3.5.26Talos is built with Go 1.24.11.
​
v1.10.8
Talos
Release notes →

​
Component Updates

Linux: 6.12.58 Kubernetes: 1.33.6 Runc: v1.2.8 Containerd: v2.0.7Talos is built with Go 1.24.10.
​
v1.10.7
Talos
Release notes →

​
Component Updates

Linux: 6.12.43 Kubernetes: 1.33.4Talos is built with Go 1.24.6.
​
v1.10.6
Talos
Release notes →

​
Component Updates

Linux: 6.12.40 Kubernetes: 1.33.3Talos is built with Go 1.24.5.
​
v1.10.5
Talos
Release notes →

​
Azure

Talos on Azure now defaults to MTU of 1400 bytes for the eth0 interface to avoid packet fragmentation issues. The default MTU can be overriden with machine configuration.

​
Component Updates

Linux: 6.12.35 Kubernetes: 1.33.2Talos is built with Go 1.24.4.
​
v1.10.4
Talos
Release notes →

​
Component Updates

Linux: 6.12.31Talos is built with Go 1.24.4.
​
v1.10.3
Talos
Release notes →

​
Component Updates

Linux: 6.12.28 Kubernetes: 1.33.1Talos is built with Go 1.24.3.
​
v1.10.2
Talos
Release notes →

​
Component Updates

Linux: 6.12.27Talos is built with Go 1.24.3.
​
v1.10.0
Talos
Release notes →

​
auditd

Kernel parameter talos.auditd.disabled=1 can be used to disable Talos built-in auditd service.

​
cgroups v1

Talos Linux no longer supports cgroupsv1 when running in non-container mode. The kernel argument talos.unified_cgroup_hierarchy is now ignored.

​
Disk Image

Talos starting with 1.10 will have disk images that will use GRUB only for legacy BIOS and systemd-boot for modern UEFI systems. On first boot Talos determines the boot method and will wipe the unused bootloader.Secureboot disk-images will be sd-boot only.For ARM64 imager will still generate GRUB bootloader for Talos < 1.10 and for Talos >= 1.10 all ARM64 boot assets will use systemd-boot.Imager supports overwriting bootloader when generating a disk image via the Imager profile output option.Eg:
output:
  kind: image
  imageOptions:
    bootloader: sd-boot # supported options are sd-boot, grub, dual-boot

​
Driver Rebind

Talos 1.10 now supports a new machine config document named PCIDriverRebindConfig that allows rebinding the driver of a PCI device to a different target driver. See the documentation for more information.

​
Ethernet

Talos now provides ethtool-style Ethernet low-level configuration via network/EthernetConfig documents. Current status of the interface can be read by talosctl get ethernetstatus.

​
Machine Install Extensions

.machine.install.extensions will have no effect starting from Talos 1.10, the machine config document field is still kept so upgrades from older versions are possible. Use Boot Assets instead.

​
Extra Kernel Args

Talos 1.10 on fresh install on UEFI systems will now use systemd-boot and UKIs (Unified Kernel Images)[https://uapi-group.org/specifications/specs/unified_kernel_image/]. This means the kernel command line arguments are part of the UKI and cannot be modified without an upgrade to a new UKI.Upgrades to Talos 1.10 will preseve the existing bootloader (GRUB for non-secureboot) and sd-boot for Secureboot and this change will have no effect.To build a boot asset with extra kernel arguments whether an installer or a boot image use either Image Factory or Imager.This means kernel arguments not part of the UKI will not be preserved across updates and a proper installer image generated via Imager Factory or Imager is required.

​
Ingress Firewall

Talos Ingress Firewall now filters access to Kubernetes NodePort services correctly.

​
iSCSI Initiator

Talos now generates /etc/iscsi/initiatorname.iscsi file based on the node identity which is tied to the lifecycle of the node. If using iscsi-tools extension, starting with Talos 1.10 would have a more deterministic IQN for the initiator node. Make sure to update any iSCSI targets to use the new initiator IQN.The iqn can be read by talosctl read /etc/iscsi/initiatorname.iscsi

​
ISO

Talos starting with 1.10 will have ISO’s that will use GRUB only for legacy BIOS and systemd-boot for modern UEFI systems.

​
kube-apiserver Authorization Config

When using .cluster.apiServer.authorizationConfig the user provided order for the authorizers is honoured and Node and RBAC authorizers are always added to the end if not explicitly specified.Eg: If user provides only Webhook authorizer, the final order will be Webhook, Node, RBAC.To provide a specific order for Node or RBAC explicitly, user can provide the authorizer in the order they want.Eg:
cluster:
  apiServer:
    authorizationConfig:
      - type: Node
        name: Node
      - type: Webhook
        name: Webhook
        webhook:
          connectionInfo:
            type: InClusterConfig
        ...
      - type: RBAC
        name: rbac
Usage of authorization-mode CLI argument will not support this form of customization.

​
NVMe NQN

Talos now generates /etc/nvme/hostnqn and /etc/nvme/hostid files based on the node identity which is tied to the lifecycle of the node.The NQN can be read by talosctl read /etc/nvme/hostnqn

​
SELinux

Talos now supports enabling SELinux enforcing mode, see SELinux for more details.

​
Fully bootstrapped builds

Talos 1.10 is built with a toolchain based on [Stageˣ], which is a project building fully bootstrapped software. This change increases reproducibility, auditability and security of Talos builds.This also changes Talos root filesystem structure for unified /usr, with other directories symlinking to /usr/bin and /usr/lib. System extensions must move their directories accordingly for 1.10.

​
Component Updates

  • Linux: 6.12.25
  • CNI plugins: 1.6.2
  • runc: 1.2.6
  • containerd: 2.0.5
  • etcd: 3.5.20
  • Flannel: 0.26.7
  • Kubernetes: 1.33.0
  • CoreDNS: 1.12.1
Talos is built with Go 1.24.2.

​
User Volumes

Talos now supports user disk volumes via the UserVolumeConfig machine config document.The old .machine.disks field is deprecated, but still supported for backwards compatibility.
​
v1.9.6
Talos
Release notes →

​
Component Updates

  • Linux: 6.12.25
  • containerd: 2.0.5
  • runc: 1.2.6
  • Kubernetes: 1.32.4
  • etcd: 3.5.21
Talos is built with Go 1.23.8.
​
v1.9.5
Talos
Release notes →

​
Component Updates

  • Linux: 6.12.18
  • containerd: 2.0.3
  • runc: 1.2.5
  • Kubernetes: 1.32.3
  • etcd: 3.5.19
Talos is built with Go 1.23.7.
​
v1.9.4
Talos
Release notes →

​
Ingress Firewall

Talos Ingress Firewall now filters access to Kubernetes NodePort services correctly.

​
Component Updates

  • Linux: 6.12.13
  • Flannel: 0.26.4
  • Kubernetes: 1.32.2
Talos is built with Go 1.23.6.
​
v1.9.3
Talos
Release notes →

​
Component Updates

  • Linux: 6.12.11
  • Kubernetes: 1.32.1
  • etcd: 3.5.18
Talos is built with Go 1.23.5.
​
v1.9.2
Talos
Release notes →

​
auditd

Kernel parameter talos.auditd.disabled=1 can be used to disable Talos built-in auditd service.

​
kube-apiserver Authorization Config

When using .cluster.apiServer.authorizationConfig the user provided order for the authorizers is honoured and Node and RBAC authorizers are always added to the end if not explicitly specified.Eg: If user provides only Webhook authorizer, the final order will be Webhook, Node, RBAC.To provide a specific order for Node or RBAC explicitly, user can provide the authorizer in the order they want.Eg:
cluster:
  apiServer:
    authorizationConfig:
      - type: Node
        name: Node
      - type: Webhook
        name: Webhook
        webhook:
          connectionInfo:
            type: InClusterConfig
        ...
      - type: RBAC
        name: rbac
Usage of authorization-mode CLI argument will not support this form of customization.

​
Component Updates

  • Linux: 6.12.9
  • runc: 1.2.4
  • containerd: 2.0.2
Talos is built with Go 1.23.4.
​
v1.9.1
Talos
Release notes →

​
Component Updates

  • Linux: 6.12.6
  • CNI plugins: 1.6.1
Talos is built with Go 1.23.4.
​
v1.9.0
Talos
Release notes →

​
Auditd

Talos Linux now starts an auditd service by default. Logs can be read with talosctl logs auditd.

​
talosctl cgroups

The talosctl cgroups command has been added to the talosctl tool. This command allows you to view the cgroup resource consumption and limits for a machine, e.g. talosctl cgroups --preset memory.

​
cgroups version 1

Support for cgroupsv1 is deprecated, and will be removed in Talos 1.10 (for non-container mode).

​
Custom search domains for Talos nodes

Talos now allows to supports specifying custom search domains for Talos nodes using new config field machine.network.searchDomainsFor the host it will look something like this:
nameserver 127.0.0.53

search my-custom-search-name.com my-custom-search-name2.com
For the pods it will look something like this:
search default.svc.cluster.local svc.cluster.local cluster.local my-custom-search-name.com my-custom-search-name2.com
nameserver 10.96.0.10
options ndots:5

​
Device Selectors

Talos now supports matching on permanent hardware (MAC) address of the network interfaces. This is specifically useful to match bond members, as they change their hardware addresses when they become part of the bond.

​
Direct Rendering Manager (DRM)

Starting with Talos 1.9, the i915 and amdgpu DRM drivers will be dropped from the Talos squashfs. There will be new system extensions named i915 and amdgpu that would contain both the drivers and firmware packaged together. Upgrades via Image Factory will automatically include the new extensions if previously i915-ucode or amdgpu-firmware were used.

​
Image Cache

Talos now supports providing a local Image Cache for container images.

​
Kube APIServer Authorization Config

Starting with Talos 1.9, .cluster.apiServer.authorizationConfig field supports setting Kubernetes API server authorization modes using the --authorization-config flag.The machine config field supports a list of authorizers. For instance:
cluster:
  apiServer:
    authorizationConfig:
      - type: Node
        name: Node
      - type: RBAC
        name: rbac
For new cluster if the Kubernetes API server supports the --authorization-config flag, it’ll be used by default instead of the --authorization-mode flag. By default Talos will always add the Node and RBAC authorizers to the list.When upgrading if either a user-provided authorization-mode or authorization-webhook-* flag is set via .cluster.apiServer.extraArgs, it’ll be used instead of the new AuthorizationConfig.Current authorization config can be viewed by running: talosctl get authorizationconfigs.kubernetes.talos.dev -o yaml

​
Node Address Sort

Talos supports new experimental address sort algorithm for NodeAddress which are used to pick up default addresses for kubelet, etcd, etc.It can be enabled with the following config patch:
machine:
  features:
    nodeAddressSortAlgorithm: v2

​
OCI Base Runtime Spec

Talos now allows to modify the OCI base runtime spec for the container runtime.

​
Registry Mirrors

In versions before Talos 1.9, there was a discrepancy between the way Talos itself and CRI plugin resolves registry mirrors: Talos will never fall back to the default registry if endpoints are configured, while CRI plugin will.
Note: Talos Linux pulls images for the installer, kubelet, etcd, while all workload images are pulled by the CRI plugin.
In Talos 1.9 this was fixed, so that by default an upstream registry is used as a fallback in all cases, while new registry mirror configuration option .skipFallback can be used to disable this behavior both for Talos and CRI plugin.

​
talosctl disks

The command talosctl disks was removed, please use talosctl get disks, talosctl get systemdisk, and talosctl get blockdevices instead.

​
talosctl wipe

The new command talosctl wipe disk allows to wipe a disk or a partition which is not used as a volume.

​
udevd

Talos previously used eudev to provide udevd, now it uses systemd-udevd instead.

​
Component Updates

  • Linux: 6.12.5
  • containerd: 2.0.1
  • Flannel: 0.26.1
  • Kubernetes: 1.32.0
  • runc: 1.2.3
  • CoreDNS: 1.12.0
Talos is built with Go 1.23.4.

​
User Namespaces

Talos Linux now supports running Kubernetes pods with user namespaces enabled. Refer to the documentation for more information.
​
v1.8.4
Talos
Release notes →Starting with Talos v1.8.0, only standard assets would be published as github release assets. These include:
  • cloud-images.json
  • talosctl binaries
  • kernel
  • initramfs
  • metal iso and disk images
  • talosctl-cni-bundle
All other release assets can be downloaded from Image Factory.

​
Component Updates

Linux: 6.6.64 runc: 1.2.3 Kubernetes: 1.31.4 etcd: 3.5.17Talos is built with Go 1.22.10.
​
v1.8.3
Talos
Release notes →Starting with Talos v1.8.0, only standard assets would be published as github release assets. These include:
  • cloud-images.json
  • talosctl binaries
  • kernel
  • initramfs
  • metal iso and disk images
  • talosctl-cni-bundle
All other release assets can be downloaded from Image Factory.

​
Component Updates

Linux: 6.6.60 containerd: 2.0.0 runc: 1.2.1Talos is built with Go 1.22.9.
​
v1.8.2
Talos
Release notes →Starting with Talos v1.8.0, only standard assets would be published as github release assets. These include:
  • cloud-images.json
  • talosctl binaries
  • kernel
  • initramfs
  • metal iso and disk images
  • talosctl-cni-bundle
All other release assets can be downloaded from Image Factory.

​
Component Updates

Linux: 6.6.58 containerd: 2.0.0-rc.6 runc: 1.2.0 Kubernetes: 1.31.2Talos is built with Go 1.22.8.
​
v1.8.1
Talos
Release notes →Starting with Talos v1.8.0, only standard assets would be published as github release assets. These include:
  • cloud-images.json
  • talosctl binaries
  • kernel
  • initramfs
  • metal iso and disk images
  • talosctl-cni-bundle
All other release assets can be downloaded from Image Factory.

​
Component Updates

Linux: 6.6.54 containerd: 2.0.0-rc.5 Flannel: 0.25.7Talos is built with Go 1.22.8.
​
v1.8.0
Talos
Release notes →Starting with Talos v1.8.0, only standard assets would be published as github release assets. These include:
  • cloud-images.json
  • talosctl binaries
  • kernel
  • initramfs
  • metal iso and disk images
  • talosctl-cni-bundle
All other release assets can be downloaded from Image Factory.

​
Node Annotations

Talos Linux now supports configuring Kubernetes node annotations via machine configuration (.machine.nodeAnnotations) in a way similar to node labels.

​
Workload Apparmor Profile

Talos Linux can now apply the default AppArmor profiles to all workloads started via containerd, if the machine is installed with the AppArmor LSM enforced via the extraKernelArgs.Eg:
machine:
    install:
        extraKernelArgs:
            - security=apparmor

​
Bridge Interface

Talos Linux now support configuring ‘vlan_filtering’ for bridge interfaces.

​
Machine Configuration via Kernel Command Line

Talos Linux supports supplying zstd-compressed, base64-encoded machine configuration small documents via the kernel command line parameter talos.config.inline.

​
CNI Plugins

Talos Linux now bundles by default the following standard CNI plugins:
  • bridge
  • firewall
  • flannel
  • host-local
  • loopback
  • portmap
The Talos bundled Flannel manifest was simplified to remove the install-cni step.

​
Accessing /dev/net/tun in Kubernetes Pods

Talos Linux ships with runc 1.2, which drops legacy rule to expose /dev/net/tun devices by default in the container.If you need to access /dev/net/tun in your Kubernetes pods (e.g. running Tailscale as a Kubernetes pod), you can add use device plugins to expose /dev/net/tun to the pod.

​
Diagnostics

Talos Linux now shows diagnostics information for common problems related to misconfiguration via talosctl health and Talos dashboard.

​
Disk Management

Talos Linux now supports configuration for the EPHEMERAL volume.

​
Extensions in Kubernetes Nodes

Talos Linux now publishes list of installed extensions as Kubernetes node labels/annotations.The key format is extensions.talos.dev/<name> and the value is the extension version. If the extension name is not valid as a label key, it will be skipped. If the extension version is a valid label value, it will be put to the label; otherwise it will be put to the annotation.For Talos machines booted of the Image Factory artifacts, this means that the schematic ID will be published as the annotation extensions.talos.dev/schematic (as it is longer than 63 characters).

​
DNS Forwarding for CoreDNS pods

Usage of the host DNS resolver as upstream for Kubernetes CoreDNS pods is now enabled by default. You can disable it with:
machine:
  features:
    hostDNS:
      enabled: true
      forwardKubeDNSToHost: false
Please note that on running cluster you will have to kill CoreDNS pods for this change to apply.The IP address used to forward DNS queries has changed to the fixed 169.254.116.108 address. For those upgrading from Talos 1.7 with forwardKubeDNSToHost enabled, the old Kubernetes service can be cleaned up with kubectl delete -n kube-system service host-dns.

​
Installer

Talos Linux installer now never wipes the system disk on upgrades, which means that the flag --preserve is always set for talosctl upgrade.

​
talos.halt_if_installed kernel argument

Starting with Talos 1.8, ISO’s generated from Boot Assets would have a new kernel argument talos.halt_if_installed which would pause the boot sequence until boot timeout if Talos is already installed on the disk. ISO generated for pre 1.8 versions would not have this kernel argument.This can be also explicitly enabled by setting talos.halt_if_installed=1 in kernel argument.

​
Slim Kubelet Image

Kubelet container image includes various utilities that kubelet might use to perform various tasks.Starting with Kubernetes 1.31.0, kubelet image now includes less utilities, as the in-tree CSI plugins were removed in Kubernetes 1.31.0. This reduces kubelet image size and potential attack surface.For Kubernetes < 1.31.0, there will be two images built:
  • v1.x.y (default, fat)
  • v1.x.y-slim (slim)
For Kubernetes >= 1.31.0, there will be same two images built, but the default tag would point to slim image:
  • v1.x.y (default, slim)
  • v1.x.y-fat (fat)

​
KubeSpan

Extra announced endpoints can be added using the KubespanEndpointsConfig document.

​
Default Node Labels

Talos Linux on config generation now adds a label node.kubernetes.io/exclude-from-external-load-balancers by default for the control plane nodes.

​
PCI Devices

A list of PCI devices can now be obtained via PCIDevices resource, e.g. talosctl get pcidevices.

​
Metal images

Starting with Talos 1.8, console=ttyS0 kernel argument is removed from the metal images and installer. If running virtualized in QEMU (For eg: Proxmox), this can be added as an extra kernel argument if needed via Image Factory or using Imager.This should fix slow boot or no console output issues on most bare metal hardware.

​
NVIDIA GPU Support

Starting with Talos 1.8.0, SideroLabs would ships extensions for both LTS and Production versions of NVIDIA extensions. For more details see the CHANGELOG of extensions.Upgrades with an exisiting schematic id from Image Factory would keep the existing LTS version of the NVIDIA extension.

​
Removing parts of the configuration using $patch: delete syntax

Talos Linux now supports removing parts of the configuration using the $patch: delete syntax similar to the kubernetes. More information can be found here.

​
Platform Support

Talos Linux now supports Apache CloudStack platform.

​
kube-proxy

Talos Linux configures kube-proxy >= v1.31.0 to use ‘nftables’ backend by default.

​
Secure Boot

Talos Linux now can optionally include well-known UEFI (Microsoft) SecureBoot keys into the auto-enrollment UEFI database.

​
Custom Trusted Roots

Talos Linux now supports adding custom trusted roots (CA certificates) via TrustedRootsConfig configuration documents.

​
Device Extra Settle Timeout

Talos Linux now supports a kernel command line argument talos.device.settle_time=3m to set the device extra settle timeout to workaround issues with broken drivers.

​
Component Updates

Kubernetes: 1.31.1 Linux: 6.6.52 containerd: 2.0.0-rc.4 runc: 1.2.0-rc.3 etcd: 3.5.16 Flannel: 0.25.6 Flannel CNI plugin: 1.5.1 CoreDNS: 1.1.13Talos is built with Go 1.22.7.

​
ZSTD Compression

Talos Linux now compresses kernel and initramfs using ZSTD. Linux arm64 kernel is now compressed (previously it was uncompressed).
​
v1.7.7
Talos
Release notes →

​
Component Updates

Linux: 6.6.52 Kubernetes: 1.30.5 containerd: 1.7.22 runc: 1.1.14Talos is built with Go 1.22.7.
​
v1.7.6
Talos
Release notes →

​
Component Updates

Linux: 6.6.43 Kubernetes: 1.30.3Talos is built with Go 1.22.5.
​
v1.7.5
Talos
Release notes →

​
Component Updates

Linux: 6.6.33 Flannel: 0.25.3 Containerd: 1.7.18Talos is built with Go 1.22.4.
​
v1.7.4
Talos
Release notes →

​
Component Updates

Talos is built with Go 1.22.3.
​
v1.7.3
Talos
Release notes →

​
Component Updates

Linux: 6.6.32Talos is built with Go 1.22.3.
​
v1.7.2
Talos
Release notes →

​
Component Updates

Kubernetes: 1.30.1 Linux: 6.6.30Talos is built with Go 1.22.3.
​
v1.7.1
Talos
Release notes →

​
Component Updates

Linux: 6.6.29 containerd: 1.7.16Talos is built with Go 1.22.2.
​
v1.7.1
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

A EULA agreement has been added to Omni which must be accepted in order to continue using it.This agreement can be accepted through UI or programmatically either by adding the below flags:
--eula-accept-name=Your Name
--eula-accept-email=your@email.com
Or if using --config-path with the below configuration:
eulaAccept:
  name: Your Name
  email: your@email.com
​
v1.7.0
Talos
Release notes →Documentation on What’s New in Talos 1.7.0

​
CA Rotation

Talos Linux now supports rotating the root CA certificate and key for Talos API and Kubernetes API.

​
Device Selectors

Talos Linux now supports physical: true qualifier for device selectors, it selects non-virtual network interfaces (i.e. en0 is selected, while bond0 is not).

​
DNS Caching

Talos Linux now provides a caching DNS resolver for host workloads (including host networking pods). It can be disabled with:
machine:
  features:
    hostDNS:
      enabled: false
You can also enable dns caching for k8s pods with:
machine:
  features:
    hostDNS:
      enabled: true
      forwardKubeDNSToHost: true
Please note that on running cluster you will have to kill CoreDNS pods for this change to apply.If you want to can also enable the resolving of member addresses through their host and node names:
machine:
  features:
    hostDNS:
      enabled: true
      resolveMemberNames: true

​
Extension Services Config

Talos now supports supplying configuration files and environment variables for extension services. The extension service configuration is a separate config document. An example is shown below:
---
apiVersion: v1alpha1
kind: ExtensionServiceConfig
name: nut-client
configFiles:
  - content: MONITOR ${upsmonHost} 1 remote pass password
    mountPath: /usr/local/etc/nut/upsmon.conf
environment:
  - UPS_NAME=ups
For documentation, see Extension Services Config Files.Note: The use of environmentFile in extension service spec is now deprecated and will be removed in a future release of Talos. Use ExtensionServiceConfig instead.

​
IPTables

Talos Linux now forces kubelet and kube-proxy to use iptables-nft instead of iptables-legacy (xtables) which was the default before Talos 1.7.0.Container images based on iptables-wrapper should work without changes, but if there was a direct call to legacy mode of iptables, make sure to update to use iptables-nft.

​
Kubernetes Upgrade

The command talosctl upgrade-k8s now supports specifying custom image references for Kubernetes components via --*-image flags. The default behavior is unchanged, and the flags are optional.

​
KubeSpan

Talos Linux disables by default a KubeSpan feature to harvest additional endpoints from KubeSpan members. This feature turned out to be less helpful than expected and caused unnecessary performance issues.Previous behavior can be restored with:
machine:
  network:
    kubespan:
        harvestExtraEndpoints: true

​
Logging

Talos Linux now supports setting extra tags when sending logs in JSON format:
machine:
  logging:
    destinations:
      - endpoint: "udp://127.0.0.1:12345/"
        format: "json_lines"
        extraTags:
          server: s03-rack07

​
Time Sync

Default NTP server was updated to be time.cloudflare.com instead of pool.ntp.org. Default server is only used if the user does not specify any NTP servers in the configuration.Talos Linux can now sync to PTP devices (e.g. provided by the hypervisor) skipping the network time servers. In order to activate PTP sync, set machine.time.servers to the PTP device name (e.g. /dev/ptp0):
machine:
  time:
    servers:
      - /dev/ptp0

​
OpenNebula

Talos Linux now supports OpenNebula platform.

​
Platforms

Talos Linux now supports Akamai Connected Cloud provider (platform akamai).

​
Kubernetes API Server Service Account Key

Talos Linux starting from this release uses RSA key for Kubernetes API Server Service Account instead of ECDSA key to provide better compatibility with external OpenID Connect implementations.

​
SBC

Talos has split the SBC’s (Single Board Computers) into separate repositories. There will not be any more SBC specific release assets as part of Talos release.The default Talos Installer image will stop working for SBC’s and will fail the upgrade, if used, starting from Talos v1.7.0.The SBC’s images and installers can be generated on the fly using Image Factory or using Imager for custom images. The list of official SBC’s images supported by Image Factory can be found in the Overlays repository.

​
Secure Boot Image

Talos Linux now provides a way to configure systemd-boot ISO ‘secure-boot-enroll’ option while generating a SecureBoot ISO image:
output:
    kind: iso
    isoOptions:
        sdBootEnrollKeys: force # default is still if-safe
    outFormat: raw

​
Syslog

Talos Linux now starts a basic syslog receiver listening on /dev/log. The receiver can mostly parse both RFC3164 and RFC5424 messages and writes them as JSON formatted message. The logs can be viewed via talosctl logs syslogd.This is mostly implemented for extension services that log to syslog.

​
Component Updates

Linux: 6.6.28 etcd: 3.5.11 Kubernetes: 1.30.0 containerd: 1.7.15 runc: 1.1.12 Flannel: 0.25.1Talos is built with Go 1.22.2.

​
Hardware Watchdog Timers

Talos Linux now supports hardware watchdog timers configuration. If enabled, and the machine becomes unresponsive, the hardware watchdog will reset the machine.The watchdog can be enabled with the following configuration document:
apiVersion: v1alpha1
kind: WatchdogTimerConfig
device: /dev/watchdog0
timeout: 3m0s
​
v1.7.0
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

A EULA agreement has been added to Omni which must be accepted in order to continue using it.This agreement can be accepted through UI or programmatically either by adding the below flags:
--eula-accept-name=Your Name
--eula-accept-email=your@email.com
Or if using --config-path with the below configuration:
eulaAccept:
  name: Your Name
  email: your@email.com

​
Allow Machine Request Destroy

Machine requests are now created without a controller owner, allowing operators and admins to teardown stuck or unwanted requests directly. The controller replaces destroyed requests automatically to maintain the desired machine count.

​
Browsable Audit Logs in the UI

Audit logs are now browsable directly in the Omni UI, making it easier to review audit events without CLI access.

​
Human-Readable Config Validation Errors

Configuration validation errors are now presented in a human-readable format, making it easier to diagnose and fix configuration issues.

​
Move Omni Defaults to JSONSchema

Omni default config values are now defined in the JSONSchema.All Talos nodes can now be accessed directly via their SideroLink endpoint, removing the need to route through the load balancer for Talos API calls. Allowing direct access to worker nodes when control plane nodes are unavailable.

​
Kubernetes Manifests Sync

Omni now supports syncing Kubernetes manifests directly to managed clusters. Manifests can be defined in cluster templates, allowing declarative management of Kubernetes resources alongside cluster configuration.

​
omnictl edit Command

A new omnictl edit command has been added, allowing users to edit Omni resources interactively from the CLI.

​
Allow Using talosctl debug

Update Omni Talos API proxy code to elevate permissions for talosctl debug command.

​
Workload Proxy Subdomain Options

The workload proxy now supports an empty subdomain configuration and a new useOmniSubdomain option, providing more flexibility in how workload proxy URLs are structured.
​
v1.6.8
Talos
Release notes →

​
Component Updates

  • Linux: 6.1.100
  • Kubernetes: 1.29.7
  • runc: 1.1.13
  • containerd: 1.7.20
Talos is built with Go 1.21.12.
​
v1.6.7
Talos
Release notes →

​
Component Updates

  • Linux: 6.1.82
  • Kubernetes: 1.29.3
Talos is built with Go 1.21.8.
​
v1.6.6
Talos
Release notes →

​
Component Updates

  • Linux: 6.1.80
Talos is built with Go 1.21.8.
​
v1.6.5
Talos
Release notes →

​
Kubernetes Upgrade

The command talosctl upgrade-k8s now supports specifying custom image references for Kubernetes components via --*-image flags. The default behavior is unchanged, and the flags are optional.

​
Component Updates

Kubernetes: 1.29.2 Linux: 6.1.78Talos is built with Go 1.21.6.
​
v1.6.5
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

The deprecated flags and config fields that were kept for the SQLite migration period (introduced in v1.4.0) have been removed.If you still have any of the following flags or config keys set, you must remove them before upgrading, as they will cause startup errors:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --log-storage-path (.logs.machine.storage.path)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
The automatic migration code for BoltDB secondary storage, file-based audit logs, file-based discovery service snapshots, and circular buffer machine logs has also been removed. If you are upgrading from a version older than v1.4.0, you must first upgrade to v1.4.x to complete the migrations, then upgrade to this version.
​
v1.6.4
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

The deprecated flags and config fields that were kept for the SQLite migration period (introduced in v1.4.0) have been removed.If you still have any of the following flags or config keys set, you must remove them before upgrading, as they will cause startup errors:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --log-storage-path (.logs.machine.storage.path)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
The automatic migration code for BoltDB secondary storage, file-based audit logs, file-based discovery service snapshots, and circular buffer machine logs has also been removed. If you are upgrading from a version older than v1.4.0, you must first upgrade to v1.4.x to complete the migrations, then upgrade to this version.
​
v1.6.4
Talos
Release notes →

​
Component Updates

containerd: 1.7.13 runc: 1.1.12See CVE-2024-21626 for the runc update.Talos is built with Go 1.21.6.
​
v1.6.3
Talos
Release notes →

​
Component Updates

Linux: 6.1.74 Kubernetes: 1.29.1Talos is built with Go 1.21.6.
​
v1.6.3
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

The deprecated flags and config fields that were kept for the SQLite migration period (introduced in v1.4.0) have been removed.If you still have any of the following flags or config keys set, you must remove them before upgrading, as they will cause startup errors:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --log-storage-path (.logs.machine.storage.path)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
The automatic migration code for BoltDB secondary storage, file-based audit logs, file-based discovery service snapshots, and circular buffer machine logs has also been removed. If you are upgrading from a version older than v1.4.0, you must first upgrade to v1.4.x to complete the migrations, then upgrade to this version.
​
v1.6.2
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

The deprecated flags and config fields that were kept for the SQLite migration period (introduced in v1.4.0) have been removed.If you still have any of the following flags or config keys set, you must remove them before upgrading, as they will cause startup errors:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --log-storage-path (.logs.machine.storage.path)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
The automatic migration code for BoltDB secondary storage, file-based audit logs, file-based discovery service snapshots, and circular buffer machine logs has also been removed. If you are upgrading from a version older than v1.4.0, you must first upgrade to v1.4.x to complete the migrations, then upgrade to this version.
​
v1.6.2
Talos
Release notes →

​
Component Updates

Linux: 6.1.73Talos is built with Go 1.21.6.
​
v1.6.1
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

The deprecated flags and config fields that were kept for the SQLite migration period (introduced in v1.4.0) have been removed.If you still have any of the following flags or config keys set, you must remove them before upgrading, as they will cause startup errors:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --log-storage-path (.logs.machine.storage.path)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
The automatic migration code for BoltDB secondary storage, file-based audit logs, file-based discovery service snapshots, and circular buffer machine logs has also been removed. If you are upgrading from a version older than v1.4.0, you must first upgrade to v1.4.x to complete the migrations, then upgrade to this version.
​
v1.6.1
Talos
Release notes →

​
Component Updates

Linux: 6.1.69 containerd: 1.7.11Talos is built with Go 1.21.5.
​
v1.6.0
Talos
Release notes →

​
OAuth2 Machine Config Flow

Talos Linux when running on the metal platform can be configured to authenticate the machine configuration download using OAuth2 device flow.

​
Network Device Selectors

Previously, network device selectors only matched the first link, now the configuration is applied to all matching links.

​
Extension Services

Talos now starts Extension Services early in the boot process, this allows guest agents to be started in maintenance mode.

​
Linux Firmware

Starting with Talos 1.6, there is no Linux firmware included in the initramfs. Customers who need Linux firmware can pull them as extension during install time using the image factory service. If the initial boot requires firmware, a custom iso can be built with the firmware included using the image factory service. This also ensures that the linux-firmware is not tied to a specific Talos version.

​
Flannel Configuration

Talos Linux now supports customizing default Flannel manifest with extra arguments for flanneld.
cluster:
  network:
    cni:
      flannel:
        extraArgs:
          - --iface-can-reach=192.168.1.1

​
Ingress Firewall

Talos Linux now supports configuring the ingress firewall rules.

​
Kernel Arguments

Talos and Imager now supports dropping kernel arguments specified in .machine.install.extraKernelArgs or as --extra-kernel-arg to imager. Any kernel argument that starts with a - is dropped. Kernel arguments to be dropped can be specified either as -<key> which would remove all arguments that start with <key> or as -<key>=<value> which would remove the exact argument.

​
Kube-Scheduler Configuration

Talos now supports specifying the kube-scheduler configuration in the Talos configuration file. It can be set under cluster.scheduler.config and kube-scheduler will be automatically configured to with the correct flags.

​
Kubelet Credential Provider Configuration

Talos now supports specifying the kubelet credential provider configuration in the Talos configuration file. It can be set under machine.kubelet.credentialProviderConfig and kubelet will be automatically configured to with the correct flags. The credential binaries are expected to be present under /usr/local/lib/kubelet/credentialproviders. Talos System Extensions can be used to install the credential binaries.

​
KubePrism

KubePrism is enabled by default on port 7445.

​
Sysctl

Talos now handles sysctl/sysfs key names in line with sysctl.conf(5):
  • if the first separator is ’/’, no conversion is done
  • if the first separator is ’.’, dots and slashes are remapped
Example (both sysctls are equivalent):
machine:
  sysctls:
    net/ipv6/conf/eth0.100/disable_ipv6: "1"
    net.ipv6.conf.eth0/100.disable_ipv6: "1"

​
talosctl CLI

The command images deprecated in Talos 1.5 was removed, please use talosctl images default instead.

​
Component Updates

Linux: 6.1.67 containerd: 1.7.10 CoreDNS: 1.11.1 Kubernetes: 1.29.0 Flannel: 0.23.0 etcd: 3.5.11 runc: 1.1.10Talos is built with Go 1.21.5.

​
User Disks

Talos Linux now supports specifying user disks in .machine.disks machine configuration links via udev symlinks, e.g. /dev/disk/by-id/XXXX.
​
v1.6.0
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

The deprecated flags and config fields that were kept for the SQLite migration period (introduced in v1.4.0) have been removed.If you still have any of the following flags or config keys set, you must remove them before upgrading, as they will cause startup errors:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --log-storage-path (.logs.machine.storage.path)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
The automatic migration code for BoltDB secondary storage, file-based audit logs, file-based discovery service snapshots, and circular buffer machine logs has also been removed. If you are upgrading from a version older than v1.4.0, you must first upgrade to v1.4.x to complete the migrations, then upgrade to this version.

​
Talos and Kubernetes CA Rotation

Omni now supports rotating the Talos and Kubernetes Certificate Authorities for managed clusters.

​
Talos and Kubernetes Versions in ClusterStatus

The ClusterStatus resource now includes talos_version and kubernetes_version fields, making cluster version information available programmatically. They are now also shown in the cluster list in the UI.

​
Pending and Historical Config Diffs in UI

The UI now shows pending and historical configuration diffs, making it easy to review what changed and when.

​
Force Machine Destroy

A --force flag has been added to the machine destroy command (and a corresponding UI option) to forcibly remove machines that are stuck or unresponsive.

​
Helm Chart v2

A new Helm chart v2 has been implemented with improved structure and more configurable options. More configuration values are now exposed in the Helm chart, giving operators greater flexibility when deploying Omni.

​
Installation Media Wizard

The installation media flow now uses a wizard-based UI by default, replacing the previous modal dialog. Presets may now also be saved, allowing for future reuse.

​
Machine Log Storage Cleanup

Global size-based cleanup has been added for machine log storage, preventing unbounded disk usage. Configurable options for audit log cleanup have also been added.

​
Minimum Talos Version Bump

The minimum supported Talos version for new clusters has been bumped to 1.8.

​
Minor UI Improvements

Other minor UI improvements part of this release:
  • Talos and Kubernetes versions are now shown in the cluster list.
  • Node name and UUID are shown in the support bundle modal.
  • Machine set pools now have a collapse/expand toggle.
  • Cluster scaling has been moved to a modal dialog.
  • Getting started guidance and empty-state pages have been added for clusters, machines, and machine classes.
  • Instructions for adding machines and exporting cluster templates are now shown in the UI.
  • Clarification text has been added to backup settings.
  • YouTube video embedding is now supported in documentation/onboarding flows.
  • The frontend authentication flow no longer requires an explicit login click.
  • Resource labels use new colors for improved visual clarity.

​
Detailed Node Disk Information

The node details page now shows detailed disk information, including disk model, size, and type.

​
PCI Devices on Node Details

The node details page now includes a dedicated section listing all PCI devices present on the node.

​
Reset Node Unique Tokens

It is now possible to reset the unique token for a node, which can be useful for re-enrolling machines.

​
OIDC Token Cache Isolation for Kubeconfigs

Generated kubeconfigs now use isolated OIDC token caches, preventing token collisions between different kubeconfig users.

​
Pending Machines

Machines that were previously rejected can now be unrejected from the UI, allowing them to be accepted into Omni.Rejected machines can also now be deleted directly from the UI.

​
SAML Logout Flow

Omni now implements the SAML logout flow, properly terminating sessions with the SAML identity provider on sign-out.

​
SQLite Metrics and Cleanup Counters

Metrics for the SQLite state backend have been exposed, along with cleanup counters for better observability.

​
Upgrade Parallelism

The upgrade parallelism for machine sets can now be configured via cluster templates and the UI, allowing operators to control how many machines are upgraded concurrently.

​
User and Service Account Activity Tracking

Omni now tracks the last activity time for users and service accounts, providing better visibility into account usage.

​
User Management gRPC Endpoints

New ManagementService gRPC endpoints have been added for user operations, enabling programmatic user management.

​
Configurable User and Service Account Limits

Operators can now enforce configurable limits on the number of users and service accounts that can be created in Omni.

​
Custom Vault Kubernetes Auth Mount Path

The Vault Kubernetes authentication mount path is now configurable, supporting non-default Vault configurations.
​
v1.5.0
Omni
Release notes →

​
Better Audit Logging

Omni now collects audit logs for operations performed on all user-managed resources, improving security and traceability.

​
Config Generation

Omni can now generate its own configuration directly from the defined schema. The config merge algorithms were also improved: now the config preserves the default values properly when some sections are overwritten by the user provided config.

​
Etcd Maintenance

The following etcd commands are now usable with Omni managed clusters: talosctl etcd downgrade validate talosctl etcd downgrade enable talosctl etcd downgrade cancel talosctl etcd forfeit leadership

​
gRPC Tunnel Management

Added the ability to switch gRPC tunnel modes for connected machines.

​
Join Token Management

Added a dedicated omnictl jointoken omni-endpoint to streamline node registration.

​
Kernel Args CLI Tools

Added support for managing kernel arguments directly within cluster templates.

​
Schema-Aware Code Editor

The built-in code editor for the machine configs now supports different configuration schemas for each Talos version. So the config will be always validated against the currently running Talos version schema.

​
omnictl Directory Support

The omnictl sync/apply can now process directories, simplifying bulk resource applications.

​
WireGuard Bind Address

The WireGuard endpoint (services.siderolink.wireGuard.endpoint / --siderolink-wireguard-bind-addr) is now respected. Previously, Omni always bound to all interfaces regardless of this setting. Default remains 0.0.0.0:50180.
​
v1.4.11
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.1. New Required Flag You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it. It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.2. Audit Logging Changes A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.
  • Default: true.
  • Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.
3. Automatic Migration Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.4. Deprecated Flags (Kept for Migration) The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
5. Removed Flags The following flags have been removed and are no longer supported:
  • --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
  • --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)
​
v1.4.10
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.1. New Required Flag You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it. It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.2. Audit Logging Changes A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.
  • Default: true.
  • Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.
3. Automatic Migration Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.4. Deprecated Flags (Kept for Migration) The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
5. Removed Flags The following flags have been removed and are no longer supported:
  • --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
  • --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)
​
v1.4.9
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.1. New Required Flag You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it. It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.2. Audit Logging Changes A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.
  • Default: true.
  • Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.
3. Automatic Migration Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.4. Deprecated Flags (Kept for Migration) The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
5. Removed Flags The following flags have been removed and are no longer supported:
  • --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
  • --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)
​
v1.4.8
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.1. New Required Flag You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it. It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.2. Audit Logging Changes A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.
  • Default: true.
  • Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.
3. Automatic Migration Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.4. Deprecated Flags (Kept for Migration) The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
5. Removed Flags The following flags have been removed and are no longer supported:
  • --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
  • --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)
​
v1.4.7
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.1. New Required Flag You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it. It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.2. Audit Logging Changes A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.
  • Default: true.
  • Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.
3. Automatic Migration Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.4. Deprecated Flags (Kept for Migration) The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
5. Removed Flags The following flags have been removed and are no longer supported:
  • --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
  • --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)
​
v1.4.6
Omni
Release notes →

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.1. New Required Flag You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it. It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.2. Audit Logging Changes A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.
  • Default: true.
  • Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.
3. Automatic Migration Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.4. Deprecated Flags (Kept for Migration) The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
5. Removed Flags The following flags have been removed and are no longer supported:
  • --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
  • --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)
​
v1.4.5
Omni
Release notes →
This version has a known issue with cluster state updates, please don’t use it.

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.1. New Required Flag You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it. It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.2. Audit Logging Changes A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.
  • Default: true.
  • Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.
3. Automatic Migration Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.4. Deprecated Flags (Kept for Migration) The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
5. Removed Flags The following flags have been removed and are no longer supported:
  • --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
  • --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)
​
v1.4.4
Omni
Release notes →
This version has a known issue with cluster state updates, please don’t use it.

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.1. New Required Flag You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it. It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.2. Audit Logging Changes A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.
  • Default: true.
  • Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.
3. Automatic Migration Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.4. Deprecated Flags (Kept for Migration) The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
5. Removed Flags The following flags have been removed and are no longer supported:
  • --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
  • --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)
​
v1.4.3
Omni
Release notes →
This version has a known issue with cluster state updates, please don’t use it.

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.1. New Required Flag You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it. It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.2. Audit Logging Changes A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.
  • Default: true.
  • Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.
3. Automatic Migration Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.4. Deprecated Flags (Kept for Migration) The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
5. Removed Flags The following flags have been removed and are no longer supported:
  • --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
  • --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)
​
v1.4.2
Omni
Release notes →
This version has a known issue with cluster state updates, please don’t use it.

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.1. New Required Flag You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it. It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.2. Audit Logging Changes A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.
  • Default: true.
  • Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.
3. Automatic Migration Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.4. Deprecated Flags (Kept for Migration) The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
5. Removed Flags The following flags have been removed and are no longer supported:
  • --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
  • --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)
​
v1.4.1
Omni
Release notes →
This version has a known issue with cluster state updates, please don’t use it.

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.1. New Required Flag You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it. It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.2. Audit Logging Changes A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.
  • Default: true.
  • Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.
3. Automatic Migration Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.4. Deprecated Flags (Kept for Migration) The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
5. Removed Flags The following flags have been removed and are no longer supported:
  • --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
  • --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)
​
v1.4.0
Omni
Release notes →
This version has a known issue with cluster state updates, please don’t use it.

​
Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.1. New Required Flag You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it. It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.2. Audit Logging Changes A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.
  • Default: true.
  • Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.
3. Automatic Migration Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.4. Deprecated Flags (Kept for Migration) The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:
  • --audit-log-dir (.logs.audit.path)
  • --secondary-storage-path (.storage.secondary.path)
  • --machine-log-storage-path (.logs.machine.storage.path)
  • --machine-log-storage-enabled (.logs.machine.storage.enabled)
  • --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
  • --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
  • --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
  • --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
  • --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)
5. Removed Flags The following flags have been removed and are no longer supported:
  • --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
  • --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)

​
Support for OIDC Providers without Email Verified Claim

Enabled support for OIDC providers, such as Azure, that do not provide the email_verified claim during authentication.

​
Dynamic SAML Label Role Updates

Added support for dynamically updating SAML label roles on every login via the new update_on_each_login field.

​
Machine Class Logic Updates

Added support for locks, node deletion, and restore operations when using machine classes.

​
Virtual Resources for Platform Information

Platform and SBC information is now pulled from Talos machinery and presented as virtual resources: MetalPlatformConfig, CloudPlatformConfig, and SBCConfig. They support Get and List operations.

​
Automated CLI Install Options

Automated installation options have been added to the CLI section of the homepage, supplementing the existing manual options.

​
OIDC Warning for Kubeconfig Download

A warning toast is now displayed when downloading kubeconfig to inform users that the OIDC plugin is required before using the file with kubectl.

​
UI/UX Improvements

Various UI improvements including pre-selecting the correct binary for the user’s platform, truncating long items in the ongoing tasks list, hiding JSON schema descriptions behind tooltips, and standardizing link styling.

​
Force Deletion of Infra Provider Resources

Added the ability to force-delete MachineRequests and InfraMachines managed by Infra providers. This allows for the cleanup of resources and finalizers even if the underlying provider is unresponsive or deleted.

​
Prevent Talos Minor Version Downgrades

Omni now prevents downgrading the Talos minor version below the initial version used to create the cluster. This safeguard prevents machine configurations from entering a broken state due to unsupported features in older versions.
​
v1.3.0
Omni
Release notes →

​
Shortened Auth0 Token Lifetime

Auth0 authentication tokens now expire after 2 minutes. Users without valid PGP keys will need to reauthenticate once tokens expire.

​
Cluster Import (Experimental)

Omni introduces an experimental feature that allows users to import existing Talos clusters to be managed by Omni.Documentation on how to use this feature can be found here: https://docs.siderolabs.com/omni/cluster-management/importing-talos-clusters

​
Multi-Select for Pending Machines

You can now accept or reject multiple pending machines at once, simplifying large-scale approvals.A Stripe link is now shown in the Omni settings sidebar when Stripe integration is enabled.

​
Display Unsupported Kubernetes Versions

Unsupported Kubernetes versions are now shown in the update modal as disabled entries with explanatory messages.

​
Improved Kubernetes Update Modal

The Kubernetes update modal now displays only upgradeable minor versions and explains why certain versions are not upgradeable.

​
Enhanced CPU Information in Machine Status

Machines now report processor details when either core count or frequency is available, improving visibility into hardware specs.

​
Support for Modifying Kernel Arguments

Omni now supports modifying kernel arguments for the existing machines.Documentation on how to use this feature can be found here: https://docs.siderolabs.com/omni/infrastructure-and-extensions/modify-kernel-arguments
​
v1.2.0
Omni
Release notes →

​
Cluster Locking

Cluster locking is a feature that pauses/disables all cluster related operations on a cluster.

​
Visual Feedback on Copy

Added visual feedback when copying text to the clipboard.

​
Generate Join Config for a Specific Join Token

Added the ability to generate a join configuration for a specific join token.

​
kubeconfig with grant-type=authcode-keyboard

New configs generated with the latest Omni version and authcode-keyboard enabled now work for oidc-login v1.33+. See https://github.com/int128/kubelogin/pull/1263Newly generated configs won’t work for oidc-login below v1.33. You can:
  • keep using the old configs.
  • generate the new configs and drop oidc-redirect-url param.
  • update the oidc-login module.

​
Redesigned Machine List Page

The Machines list page has been redesigned to provide a better user experience.

​
Minimum Talos version for new clusters

The minimum Talos version required to create new clusters has been raised to v1.6.0.

​
New exported metrics for cluster features and machine details

New prometheus metrics are added for:
  • Enabled cluster features: disk encryption, embedded discovery service, workload proxying.
  • Machines’ platforms, their secure boot status and whether they were booted with UKI.

​
OIDC Authentication Support

Added support for OIDC authentication in Omni.

​
Toast Messages

Replaced the notification banner feature with toast messages.Added a user consent form for Userpilot to allow opting in/out for data collection.

​
Userpilot Reporting Integration

Integrated Userpilot reporting to help track user interactions.
​
v1.2.0
Image Factory
Release notes →

​
Authentication Support (Enterprise)

Image Factory Enterprise now supports API key-based authentication. When enabled, all schematic access requires the caller to be authenticated. Each schematic records its owner at creation time, making schematics private to the user who created them. Authentication is configured via a set of usernames and associated API keys.Note: This feature is enterprise-only and is subject to the BUSL-1.1 license.

​
French Locale

The Image Factory frontend now includes a French (fr) locale, adding translations for the web interface.

​
Stable Resolution for ‘latest’ Tag

The latest tag in the registry frontend now resolves to the latest non-prerelease (stable) version instead of being passed through to the upstream registry.

​
New /talosctl/:version Endpoint

A new /talosctl/:version endpoint has been added that lists all downloadable talosctl binaries for a given Talos version.
​
v1.1.0
Image Factory
Release notes →

​
SPDX SBOM viewer

Added a new SPDX SBOM section to the Image Factory Enterprise. Users can now request SBOMs for a specific Talos schematic directly from the Image Factory Enterprise interface.Note: This feature is enterprise-only and is subject to the BUSL-1.1 license.
​
v1.1.0
Omni
Release notes →

​
Improved Clusters Page Breadcrumbs

Breadcrumbs on the clusters page have been redesigned for better navigation.

​
CLI Support for Kernel Args and Join Configs

omnictl now supports commands to retrieve SideroLink kernel arguments and join configurations.

​
Default Config Location Change

The default location for storing Omni configuration files and user PGP keys has been changed.

​
Custom Volumes in Helm Chart

Added support for specifying custom volumes and volume mounts in the Omni Helm chart.

​
Home Page Design Update

Omni home page design was changed to have more useful information about the whole account status.

​
Join Token Usage Warning

Omni now warns users when a join token is currently in use during revoke or delete operations.

​
Collapsible Sidebar on Mobile

The sidebar can now be collapsed when viewed on mobile devices, improving usability on smaller screens.

​
Join Tokens CLI

A new CLI feature has been added to manage SideroLink join tokens directly using omnictl.

​
Unique Token Status per Node

Omni now computes and displays a unique join token status for each node.
​
v1.0.17
Discovery Service
Release notes →
​
v1.0.16
Discovery Service
Release notes →
​
v1.0.15
Discovery Service
Release notes →
​
v1.0.14
Discovery Service
Release notes →
​
v1.0.13
Discovery Service
Release notes →
​
v1.0.12
Discovery Service
Release notes →
​
v1.0.11
Discovery Service
Release notes →
​
v1.0.10
Discovery Service
Release notes →
​
v1.0.9
Discovery Service
Release notes →
​
v1.0.8
Discovery Service
Release notes →
​
v1.0.7
Discovery Service
Release notes →
​
v1.0.6
Discovery Service
Release notes →
​
v1.0.5
Discovery Service
Release notes →
​
v1.0.4
Discovery Service
Release notes →
​
v1.0.3
Image Factory
Release notes →
​
v1.0.3
Discovery Service
Release notes →
​
v1.0.2
Discovery Service
Release notes →
​
v1.0.2
Image Factory
Release notes →
​
v1.0.1
Discovery Service
Release notes →
​
v1.0.1
Image Factory
Release notes →
​
v1.0.0
Image Factory
Release notes →

​
Configuration moved to env and config files only

All configuration is now provided exclusively via environment variables and/or configuration files. Command-line flags for configuration have been removed.Users must migrate any existing CLI-based configuration to env variables or supported config file formats. This change simplifies the runtime interface but is a breaking change and requires updates to existing workflows relying on CLI flags.

​
Disk Image

The disk image build process no longer requires privileged deployment and mounting ‘/dev’. The build process now operates in userspace, and it doesn’t depend on host Linux kernel anymore. This change enhances security and portability, allowing disk images to be built in a wider range of environments without elevated permissions. This also enables most of the image builds to be fully reproducible.
​
v1.0.0
Discovery Service
Release notes →
​
v0.9.0
Image Factory
Release notes →
​
v0.8.4
Image Factory
Release notes →
​
v0.8.3
Image Factory
Release notes →
​
v0.8.2
Image Factory
Release notes →
​
v0.8.1
Image Factory
Release notes →
​
v0.8.0
Image Factory
Release notes →
​
v0.7.6
Image Factory
Release notes →
​
v0.7.5
Image Factory
Release notes →
​
v0.7.4
Image Factory
Release notes →
​
v0.7.3
Image Factory
Release notes →
​
v0.7.2
Image Factory
Release notes →
​
v0.7.1
Image Factory
Release notes →
​
v0.7.0
Image Factory
Release notes →
​
v0.6.9
Image Factory
Release notes →
​
v0.6.8
Image Factory
Release notes →
​
v0.6.7
Image Factory
Release notes →
​
v0.6.6
Image Factory
Release notes →
​
v0.6.5
Image Factory
Release notes →

​
What’s Changed

​
New Contributors

Full Changelog: https://github.com/siderolabs/image-factory/compare/v0.6.4…v0.6.5
​
v0.6.4
Image Factory
Release notes →
​
v0.6.3
Image Factory
Release notes →
​
v0.6.2
Image Factory
Release notes →
​
v0.6.1
Image Factory
Release notes →
​
v0.6.0
Image Factory
Release notes →
​
v0.5.0
Image Factory
Release notes →
​
v0.4.2
Image Factory
Release notes →
​
v0.4.1
Image Factory
Release notes →
​
v0.4.0
Image Factory
Release notes →
​
v0.3.3
Image Factory
Release notes →
​
v0.3.2
Image Factory
Release notes →
​
v0.3.1
Image Factory
Release notes →
​
v0.3.0
Image Factory
Release notes →
​
v0.2.3
Image Factory
Release notes →
​
v0.2.2
Image Factory
Release notes →
​
v0.2.1
Image Factory
Release notes →
​
v0.2.0
Image Factory
Release notes →
​
v0.1.3
Discovery Service
Release notes →
​
v0.1.2
Discovery Service
Release notes →
​
v0.1.2
Image Factory
Release notes →
​
v0.1.1
Image Factory
Release notes →
​
v0.1.0
Image Factory
Release notes →