Bottlerocket and Talos Linux Release History: Versions, Updates, Support

Bottlerocket and Talos Linux are minimal, immutable operating systems built only to host containers. Bottlerocket, from Amazon, entered public preview on 10 March 2020 and reached 1.0.0 on 31 August 2020; Talos Linux, from Sidero Labs, tagged v0.1.0 on 30 July 2019 and v1.0.0 on 29 March 2022. Neither ships SSH, a shell or a package manager by default: you configure them through an API, they update by writing a whole signed image to a second partition, and they roll back if the new image will not boot.

Their support models differ in an important way. Bottlerocket bakes the Kubernetes version into a "variant" such as aws-k8s-1.36, supports each Kubernetes variant for roughly 14 months (longer on Amazon EKS extended support), and moves you to a new Kubernetes minor version by replacing nodes. Talos keeps one OS image per release, upgrades Kubernetes in place with talosctl upgrade-k8s, and gives community support to a minor release only until the next minor ships, which is about every four months. This post goes one level deeper than our Flatcar and Fedora CoreOS release history, which covers the first generation of container hosts, and sits next to our Amazon Linux release history.

Key takeaways

• Bottlerocket's CHANGELOG starts at v0.1.6 (21 October 2019). Amazon introduced it publicly on 10 March 2020, the same day v0.3.1 shipped, and announced general availability on 31 August 2020 with v1.0.0. As of 24 October 2026 the CHANGELOG reaches v1.68.0, dated 22 October 2026.
• Talos Linux tagged v0.1.0 on 30 July 2019 and v1.0.0 on 29 March 2022. The current line is 1.14 (v1.14.0 tagged 3 September 2026, v1.14.4 on 16 October 2026), with 1.15 in alpha.
• Bottlerocket variants pin an orchestrator version. Each Kubernetes variant gets updates for approximately 14 months after its first release, and aws-k8s-* variants follow the EKS policy, including extended support. Each ECS variant gets at least one year.
• Talos community support for a minor version ends when the next minor version is released. Talos 1.14 supports Kubernetes 1.33 through 1.37. Sidero Labs offers paid enterprise support beyond that.
• Bottlerocket verifies updates with The Update Framework (TUF): signed root, timestamp, snapshot and targets metadata. Talos installs signed installer images, and since 1.14 those come from the Image Factory rather than a release registry image.
• Bottlerocket ships SELinux in enforcing mode with no way to disable it, a dm-verity root filesystem, kernel lockdown in "integrity" mode on most variants, and Secure Boot on new variants since 1.15.0. Talos runs from a signed SquashFS image, enforces kernel module signatures, follows KSPP kernel hardening, and has had SELinux in permissive mode by default since 1.10.
• Both publish SBOMs: Bottlerocket writes SPDX 2.3 and CycloneDX 1.6 files into every image from v1.53.0; Talos publishes SPDX files on each GitHub release and exposes SBOMItem resources on a running node.

A dated timeline of both projects

Dates for Bottlerocket come from the headings in its CHANGELOG.md. The matching GitHub release objects are sometimes published a few days later, so treat a date as "the day the changelog says the release was cut." Dates for Talos are the dates of the git tags in the siderolabs/talos repository, cross checked against the GitHub release page where one was fetched.

Bottlerocket ships a cumulative minor release every two to six weeks with no long term branch. Talos ships a minor about three times a year and back ports fixes: v1.13.12 shipped five days after v1.14.4.

What is a minimal, immutable container host OS, and why drop SSH, a shell and a package manager?

A general purpose Linux server is a pile of packages that an administrator adds to, edits and patches one at a time. Every host drifts a little, and every tool on it, from the shell to the interpreter to the package manager, is something an attacker who lands on the box can use. A minimal container host takes the opposite position. The host exists to run a container runtime and an orchestrator agent, so everything else is removed, and the remaining operating system is shipped as one image that cannot be changed in place.

Bottlerocket's README says "there's no SSH server in a Bottlerocket image, and not even a shell." Its security features document adds that interpreted languages such as Python "are not installed or even available as packages," because shells and interpreters let an attacker "pivot from a vulnerability that grants local code execution."

Talos goes further. Its philosophy page says the userspace is "a ground-up rewrite" from PID 1, written in Go. There is no systemd; the kernel launches Talos's own machined. There are "no GNU utilities, no shell, no SSH, no packages," not even a busybox, and the SquashFS image is under 80 MB.

Removing the package manager also changes how patching works. On Bottlerocket, the docs say packages exist only at build time: "the inventory will never change for a given version and variant," and "updating to the most recent version will patch all packages." Talos works the same way, with each release producing one image whose contents are fixed. That makes both systems easy to inventory and hard to drift, but it means you cannot hot fix one library on a node. You wait for, or build, a new image.

What replaces the shell for operators?

Both projects replace interactive login with an API.

• Bottlerocket runs an HTTP API server on a local Unix domain socket. You reach it through an authenticated channel, by default a "control" host container that runs the systems manager agent, and use apiclient to read and change settings, apply updates and run reports. Settings are modeled, stored, rendered into config files on every boot and migrated across OS updates.
• Talos exposes a gRPC API on the network, secured with mutual TLS. Its philosophy page says there are "no passwords in Talos," all networked communication is "encrypted and key-authenticated," and certificates are short lived and rotate automatically. talosctl is the reference client, and it works with contexts and endpoints much like kubectl.

When you truly need a shell, both offer a controlled escape hatch. Bottlerocket has an "admin" host container, disabled by default, that runs SSH and can open a root shell on the host with sheltie. Talos has talosctl debug, which starts a privileged container from an image you supply and removes it when you exit.

Bottlerocket: origins, variants, and the API and settings model

Bottlerocket's earliest CHANGELOG entry is v0.1.6 on 21 October 2019. Amazon's container blog later wrote that "on March 10, 2020, we introduced Bottlerocket," and that date matches the v0.3.1 release. The general availability announcement on 31 August 2020 said builds for Amazon EKS were generally available and builds for Amazon ECS were in preview, and that Bottlerocket "is designed to work with any orchestrator." The README notes that almost all first party components are written in Rust.

What is a variant?

A variant is Bottlerocket's replacement for packages. The concepts page defines variants as "pre-defined sets of drivers, tools, and applications" tailored to an architecture, a platform and an orchestrator, plus an optional flavor. You never install a variant directly; you install an image that is a build of that variant at one Bottlerocket version. Image file names spell it out:

bottlerocket-[platform]-[orchestrator]-[orchestrator version](-[flavor])-[architecture]-[version]-[commit]
bottlerocket-aws-k8s-1.32-x86_64-<version>-<commit>.img

The two flavors documented today are nvidia, which adds GPU support, and fips, which constrains the kernel and userspace to cryptographic modules submitted to the FIPS 140-3 validation program. Architectures are x86_64 and aarch64.

As of the README fetched on 24 October 2026, the supported variants are:

The changelog also lists -fips and -nvidia-fips flavors and an aws-ecs-4 preview from v1.61.0.

Variants also isolate change. The security features document says the right time for an unexpected major version update to the kernel or orchestrator agent is "never." Variants peg to a kernel and GPU driver at release and receive security patches. A variant moves to a new kernel only when the old one stops getting security patches. Newer kernels arrive through new variants: v1.61.0 put non-FIPS Kubernetes 1.36 variants on kernel 6.18 and FIPS variants on 6.12, and v1.66.0 put every 1.37 variant on kernel 6.18 with containerd 2.3.

The API and settings model

Configuration lives in the API, not in files. /etc is a memory backed tmpfs, so editing /etc/resolv.conf or the containerd config directly is unsupported and does not survive a reboot. Instead you pass TOML user data at first boot, which early-boot-config turns into API calls, or you change settings later:

apiclient get settings.motd settings.kernel.lockdown
apiclient set host-containers.admin.enabled=true

Settings persist across reboots and are "migrated through OS upgrades" with migration files shipped inside the update repository. That is what lets Bottlerocket skip releases safely: the update system runs every intermediate settings migration in order.

Admin and control containers

Host containers run outside the orchestrator in a separate containerd instance.

• The control container is enabled by default and runs the systems manager agent, so you can start a session and run apiclient. You can replace it with your own image by changing its URI, or disable it, though the security guidance warns that disabling it "could leave you with no way to access the API and change settings on an existing node."
• The admin container is disabled by default. It runs an SSH server and is "superpowered," which means extra privileges, an unrestricted SELinux label and additional mounts. Inside it, sheltie gives you a full root shell on the host. The guidance recommends "leaving the 'admin' host container disabled until it is necessary to use it."

Even with root, the README warns that the dm-verity setup "will prevent most changes from persisting over a restart." Both containers are versioned components; v1.53.0 moved them to Amazon Linux 2023 bases.

Bottlerocket updates: A/B partitions, TUF and the update operator

Bottlerocket "downloads a full filesystem image and reboots into it." The disk carries two identical partition sets, A and B. An update writes the new image to the inactive set, flips the GPT priority bits, and reboots. Boot success is tracked, and if the new set fails to boot the system "will automatically revert back to the prior working partition set." You can also roll back by hand without any network call:

signpost rollback-to-inactive
reboot

How are Bottlerocket updates signed?

The update client verifies everything through The Update Framework. The updater README in the core kit describes four signed metadata files:

Any file in the manifest is also a TUF target, so it "can only be downloaded via the TUF repository, preventing the client from downloading untrusted data." Because root.json is signed by several keys with a threshold, losing some keys under that threshold does not block rotation to new keys. If you want to understand why this beats a lone signed binary, our post on whether you need TUF or whether a signed binary is enough walks through the attacks TUF's roles prevent.

The low level client, Updog, only considers version increases by default, respects a max_version in the manifest, refuses updates for a different variant, and checks that migrations exist in both directions. Updates can also carry "wave" information, so a fleet is spread out over time. Updog computes each host's position in the wave from its settings.updates.seed, and a host will not see an update until its slot arrives.

Update methods

The docs split update methods into two groups.

Brupop is a Kubernetes operator. It runs a controller deployment, an agent daemonset on every Bottlerocket node and an API server. The agent checks for updates, drains the node and applies the update when the controller says so. It uses cert-manager for its internal TLS, and only nodes labelled bottlerocket.aws/updater-interface-version=2.0.0 are updated. Brupop itself only gets security patches on its latest minor version.

Version locking uses two settings. updates.version-lock names a full version such as 1.12.0, and updates.ignore-waves=true makes the node take it immediately. Setting the lock back to latest and ignore-waves back to false returns the node to normal behaviour.

Update paths and the caveats

The in place update guidelines say you can go minor to minor, patch to patch and skip versions within one variant, because migrations run in sequence. Two caveats matter for planning:

1. Too many releases between versions. There is a known issue where a node boots into "no space left on device" when the gap is too large; the docs give 1.7.2 to 1.11.0 as an example. The workaround is to step a few releases at a time with version locking.
2. No in place move between variants or major versions. aws-k8s-1.24 to aws-k8s-1.25 is a migration, not an update. So is adding the nvidia flavor. Changing orchestrator, for example ECS to Kubernetes, means rebuilding the cluster.

How does variant support end when a Kubernetes version ages out?

The security features document states the policy. Bottlerocket "provides updates for each Kubernetes variant for approximately 14 months after the first release of each variant," and for aws-k8s-* variants it "follows the Amazon EKS support policy, including extended support beyond the typical 12 months support period." The EKS documentation, in turn, gives each Kubernetes minor version 14 months of standard support followed by 12 months of extended support, and extended support is on by default. ECS variants get updates "for at least one year after the first release," and new ECS variants appear only when a newer LTS kernel or a breaking change requires one.

In practice support ends with a changelog line: recent removals include 1.28 in v1.52.0, 1.29 in v1.58.0 and 1.30 in v1.64.0. After that release, the update repository no longer receives new images for that variant, so a node that keeps running it stops getting kernel, containerd and runc fixes even though nothing on the node visibly breaks. The README's advice is to replace those nodes "with the latest variant compatible with their cluster."

Talos Linux: origins, talosctl and the machine configuration

Talos tagged v0.1.0 on 30 July 2019 and spent almost three years in 0.x, reaching v1.0.0 on 29 March 2022 (the GitHub release is timestamped the same day). Release links in the project changelog point at a talos-systems organisation for the 0.x releases and at siderolabs from the 1.1 cycle onward. Sidero Labs builds Talos and also offers Omni, a management service for Talos clusters, and Talos Enterprise Linux with an Enterprise Image Factory; this post covers only the open source OS.

API only management through talosctl

Everything happens over the Talos API. talosctl reads its client configuration from ~/.talos/config or TALOSCONFIG, supports multiple contexts, and distinguishes endpoints (what the client connects to, which can be a load balancer or a list of control plane IPs) from nodes (the machines a command targets, proxied through an endpoint). Talos also documents role based access control for its API, so not every client needs full admin rights.

Typical read operations look like this:

talosctl --nodes 10.20.30.40 version
talosctl --nodes 10.20.30.40 get extensions
talosctl --nodes 10.20.30.40 logs kubelet
talosctl --nodes 10.20.30.40 dmesg

Machine configuration

Each machine is defined by one declarative YAML document set, which covers both Talos and the Kubernetes it forms. The philosophy page says there is "no scripting and no procedural steps," and often the same file serves many machines. Historically that file was one large v1alpha1 document. Talos 1.14 continues splitting it into small, focused documents (KubeAPIServerConfig, KubeletConfig, KubeProxyConfig, VolumeConfig and many more). The old fields still work but are deprecated, and a configuration that sets both a deprecated field and its replacement is rejected.

Talos writes only to a few controlled places. The writable partition is called EPHEMERAL precisely so nobody stores unique data there, and machine secrets live on the STATE partition. "If all else fails, we can always wipe the disk and get back up and running."

The Talos support matrix

The support matrix lists the two most recent lines.

The matrix's 1.14 release date of 27 August 2026 is an estimate; the v1.14.0 git tag is dated 3 September 2026. Platforms are tiered: tier 1 (metal, AWS, GCP) gets automated tests, tier 3 is community tested.

The git history shows patch releases on older lines after a new minor shipped (v1.12.12 on 4 September 2026, v1.13.12 on 21 October 2026), but the published policy only promises community support until the next minor. Plan on the policy. Omni adds its own floor: its version support policy says that from Omni v1.11.0, estimated for October 2026, Omni will not start if any registered machine runs a Talos version below the minimum supported version.

Talos updates: upgrade flow, Image Factory, extensions, Secure Boot and encryption

The upgrade flow

An OS upgrade is one API call that tells a node which installer image to use. Talos keeps the previous kernel and OS image in an A-B scheme. If the new version fails to boot, Talos rolls back; you can also roll back on purpose with talosctl rollback, which updates the boot reference and reboots. Because Talos reboots through kexec, the extra reboot costs little time.

Talos 1.14 changed where installer images come from. The ghcr.io/siderolabs/installer image is no longer published; installers come from the Image Factory as factory.talos.dev/<platform>-installer/<schematic-id>:<version>. For a machine without customisations, the empty schematic ID is 376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba.

talosctl upgrade --nodes 10.20.30.40 \
  --image factory.talos.dev/metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v1.14.4

Two rules shape upgrade planning:

1. Step through every minor version. Configuration migration is "only tested between adjacent minor releases," so the documented path is to move to the latest patch of each intermediate minor. Going from 1.0 to 1.2.4 means 1.0 to v1.0.6, then to v1.1.2, then to v1.2.4.
2. Kubernetes is separate. Since v1.0, an OS upgrade does not upgrade Kubernetes. You run talosctl upgrade-k8s --to <version> against a control plane node, and --dry-run shows what would change first.

Image Factory and system extensions

The Image Factory builds Talos artifacts from a "schematic," a YAML file of customisations: extra kernel arguments, initial META values, official system extensions and a board overlay. Schematics are content addressed, so the same YAML always yields the same ID, and a schematic applied to a Talos version produces a "model." The factory serves ISOs, kernel and initramfs, UKIs, cloud disk images and installer container images over HTTP, PXE and a container registry front end.

System extensions are how Talos adds things like GPU drivers, CPU microcode or extra container runtimes without a package manager. They are container images with a set folder layout, activated only at install or upgrade time, and "the Talos root filesystem is still immutable and read-only" with them installed. Since v1.5.0 Talos can generate boot media with extensions baked in. The practical consequence is that your schematic is part of your version: upgrade with the schematic ID the node was installed from, or the extensions disappear on the next upgrade.

customization:
  extraKernelArgs:
    - vga=791
  systemExtensions:
    officialExtensions:
      - siderolabs/gvisor
      - siderolabs/amd-ucode

Secure Boot and disk encryption

Talos 1.5 introduced SecureBoot using Unified Kernel Images. The current flow runs from UEFI firmware with enrolled keys, to systemd-boot, to a signed UKI. The UKI is measured into TPM PCRs, and expected measurements are signed into a policy with a PCR signing key. Combined with TPM based disk encryption, the docs call this a complete Trusted Boot experience. By default the disk key binds to PCR 7 (Secure Boot state) plus a signed PCR 11 policy. PCR binding is configurable because firmware tools now update the Secure Boot denylist often, which changes PCR 7.

Disk encryption is off by default and uses LUKS2. It can cover the STATE partition (secrets and certificates), the EPHEMERAL partition and user volumes, configured with VolumeConfig and UserVolumeConfig. Four key methods exist, and the docs rate them honestly:

apiVersion: v1alpha1
kind: VolumeConfig
name: STATE
encryption:
  provider: luks2
  keys:
    - tpm: {}
      slot: 0

Talos 1.14 also changed kernel lockdown on Secure Boot images: they no longer enable lockdown=confidentiality by default and now run with lockdown=integrity implicitly, which the release notes say improves compatibility with eBPF tooling. You can add lockdown=confidentiality back through an Image Factory schematic.

Security model comparison

Both systems start from the same idea, and they enforce it with different mechanisms.

A few details deserve a sentence each. Bottlerocket's security document admits dm-verity is "incomplete unless Secure Boot is enabled," because an attacker with the block device could rewrite both data and verity metadata; Secure Boot does not apply to legacy BIOS boot, including Xen based EC2 instance types. Sidero signs Talos release images with cosign and says its kernel, initramfs, talosctl, ISO and container builds are reproducible; Bottlerocket v1.68.0 made its builds more reproducible too. Talos 1.14 added sandboxd, which isolates containerd, the kubelet and pods in their own namespaces.

Neither project claims these controls make the kernel invulnerable. Bottlerocket's guidance says containers share the host kernel, a local kernel exploit can break other defences, and it recommends "designing for periodic host replacement even with automated updates enabled."

Bottlerocket, Talos, Flatcar and Fedora CoreOS compared

The four best known image based container hosts differ most in how you manage them and how long a version lives. Flatcar and Fedora CoreOS details come from their own docs; our Flatcar and Fedora CoreOS post covers them in depth.

Step by step: identify the version, read the notes, plan a rolling upgrade, and inventory the image

The commands below are read only unless marked otherwise. Run them first against a test cluster.

1. Identify the OS version on every node

From Kubernetes, the OS-IMAGE column comes from each node's os-release:

kubectl get nodes -o wide
kubectl get nodes -o custom-columns=NAME:.metadata.name,OS:.status.nodeInfo.osImage,KUBELET:.status.nodeInfo.kubeletVersion

On a Bottlerocket node, from a control container session:

apiclient get /updates/status

The active_partition.image block shows arch, version and variant for what is running. chosen_update shows what the node would install next, and available_updates lists every version, including older ones, because rollback is supported.

On Talos:

talosctl --nodes 10.20.30.40,10.20.30.41 version
talosctl --nodes 10.20.30.40 get extensions

The first command prints client and server versions per node; the second shows which system extensions, and therefore which schematic, the node is carrying.

2. Read the release notes for security fixes

For Bottlerocket, read CHANGELOG.md in the main repository. Recent entries split into "Security Fixes," "OS Changes" and "Orchestrator Changes," and most OS fixes arrive as kit bumps (bottlerocket-core-kit, bottlerocket-kernel-kit) whose own changelogs list the CVEs. For example, v1.62.1 patched containerd 1.7, 2.1 and 2.2 for five CVEs, and v1.63.0 patched kernels 6.1, 6.12 and 6.18 for three. Advisories live in two places: the GitHub Security tab of the repository and a gzipped updateinfo.xml file.

curl -LO https://advisories.bottlerocket.aws/updateinfo.xml.gz
gunzip updateinfo.xml.gz
grep -c "<update " updateinfo.xml

For Talos, read the GitHub release notes for your target version and the "What's New" and "Upgrading Talos Linux" pages for that minor, which list required before and after steps. Talos publishes CVE advisories in the repository's Security tab with affected versions, severity and the fixed version, and the docs explain how to watch the repository for security alerts only.

3. Plan a rolling upgrade

Bottlerocket, same variant (in place). Let Brupop handle it, or do one node by hand:

# On one canary node, from the control container
apiclient update check
apiclient update apply --check --reboot

If you need to hold a fleet on a known version while you test, lock it and later unlock it:

apiclient set updates.version-lock="1.67.0" updates.ignore-waves=true
# later
apiclient set updates.version-lock="latest" updates.ignore-waves=false

If your fleet is far behind, step through a few releases at a time to avoid the "no space left on device" issue.

Bottlerocket, new Kubernetes minor (node replacement). Upgrade the control plane first, then roll in new nodes on the matching variant (for example aws-k8s-1.37) and drain and remove the old ones. Managed node groups and eksctl both do this.

Talos, same Kubernetes, new OS minor. Upgrade one node at a time, control plane nodes before workers, and keep the schematic:

talosctl --nodes 10.20.30.40 upgrade \
  --image factory.talos.dev/metal-installer/<your-schematic-id>:v1.14.4
talosctl --nodes 10.20.30.40 health

Move through each intermediate minor's latest patch, and read the "before upgrade" notes for each; 1.14.4, for example, asks multipath users to apply a config patch first.

Talos, new Kubernetes version. After the OS is on a release that supports the target, check and then run:

talosctl --nodes 10.20.30.40 upgrade-k8s --to 1.37.1 --dry-run
talosctl --nodes 10.20.30.40 upgrade-k8s --to 1.37.1

4. Produce an SBOM or package inventory for a host image

Because both images are fixed per version, one inventory per version (and per variant or schematic) describes every node running it.

Bottlerocket. From v1.53.0, each image contains /usr/share/bottlerocket/spdx-sbom.json (SPDX 2.3) and /usr/share/bottlerocket/cyclonedx-sbom.json (CycloneDX 1.6), generated at build time by merging per package SBOMs. Older releases still have the build time inventory at /var/lib/bottlerocket/inventory/applications.json, whose objects carry Name, Version and Architecture that you can match against the pkglist entries in updateinfo.xml. To read either file you need host access, so do it on a canary node and turn the admin container off afterwards:

# Canary node only. Enable, use, then disable the admin container.
apiclient set host-containers.admin.enabled=true
apiclient exec admin bash
sheltie
cat /usr/share/bottlerocket/spdx-sbom.json
exit
apiclient set host-containers.admin.enabled=false

Talos. Download talos-amd64.spdx.json or talos-arm64.spdx.json from the GitHub release, or read SBOMs from a running node. Core OS SBOMs live in /usr/share/spdx, extension SBOMs in /usr/local/share/spdx, and both are exposed as resources:

talosctl --nodes 10.20.30.40 get sboms
talosctl --nodes 10.20.30.40 get sbom kernel -o yaml

The kernel entry includes a CPE string, which makes matching against vulnerability data straightforward. You can feed either SPDX file to an SBOM aware vulnerability scanner, including safeguard scan --sbom <file>. Talos notes that its VEX file, used to filter findings that do not apply, is available to enterprise customers.

Where Safeguard fits, honestly

Safeguard does not patch, sign or manage Bottlerocket or Talos hosts, and it does not replace either project's update system. Kernel, containerd and runc fixes for these hosts only arrive in a new OS release, so the job is to roll out the new image. What Safeguard can do is read the SBOM files both projects publish, match their components against vulnerability data next to your application SBOMs, and track which clusters still run an image version with a known issue. Policies and gates can then flag a version that should not be deployed. The larger share of risk on these hosts sits in the container images you schedule onto them, and that is where Safeguard's scanning of repositories and images, reachability analysis and remediation pull requests apply directly.

Common mistakes

• Pinning an old variant past Kubernetes support. A Bottlerocket node on aws-k8s-1.30 kept running after v1.64.0 removed that variant, but it receives no new images. Check the README's supported list each quarter and plan replacement nodes before the EKS end of support date.
• Leaving the admin container on permanently. It is superpowered, runs SSH and gets an unrestricted SELinux label. Enable it on demand and turn it off again; set enabled = false explicitly in user data so a template change cannot flip it.
• Disabling the control container without another way in. The guidance warns this "could leave you with no way to access the API." Replace it with your own control container rather than removing access entirely.
• Skipping Talos minor versions. Config migrations are tested only between adjacent minors. Jumping from 1.12 straight to 1.14 skips the 1.13 migration path.
• Upgrading Talos without the schematic. Upgrading with the vanilla installer on a node that needs GPU drivers or microcode removes those extensions. Record the schematic ID next to each node pool.
• Upgrading Kubernetes before the OS supports it. Talos 1.13 supports Kubernetes up to 1.36. Move the OS to 1.14 before you run upgrade-k8s --to 1.37.x.
• Treating dm-verity as complete on BIOS boot. Without Secure Boot, an attacker with the disk can rewrite both data and verity metadata. Prefer UEFI instance types and enable Secure Boot in firmware on metal.
• Choosing the weakest Talos encryption key. static and nodeID keys protect little against someone with the machine. Use tpm with SecureBoot, or kms.

FAQ

What is the latest version of Bottlerocket?

As of 24 October 2026, the Bottlerocket CHANGELOG lists v1.68.0, dated 22 October 2026, and the most recent GitHub release when checked was v1.67.0. Run apiclient update check on a node to see what its update repository offers, because waves can delay a release for some hosts.

What is the latest version of Talos Linux?

Talos v1.14.4 was tagged on 16 October 2026, and v1.13.12 on 21 October 2026 for the previous line. Talos 1.15 is in alpha (v1.15.0-alpha.1, 13 October 2026), and the support matrix estimates the 1.15.0 release for 27 December 2026.

How long is a Bottlerocket variant supported?

Kubernetes variants get updates for approximately 14 months after the first release of each variant, and aws-k8s-* variants follow the EKS policy, which adds 12 months of extended support after 14 months of standard support. ECS variants get at least one year.

How long is a Talos Linux version supported?

Community support for a minor version ends when the next minor version is released, so about four months. Sidero Labs offers enterprise support for longer. Patch releases have continued on older lines after a new minor in practice, but the published policy is the next minor.

How do I upgrade Kubernetes on Bottlerocket?

Kubernetes is part of the variant name, so moving from 1.36 to 1.37 is a migration to aws-k8s-1.37, not an in place update. Upgrade the control plane, then replace nodes with the new variant through your node group, eksctl or launch templates.

How do I upgrade Kubernetes on Talos?

Run talosctl upgrade-k8s --to <version> against a control plane node after confirming your Talos version supports that Kubernetes version. Use --dry-run first. OS upgrades never change the Kubernetes version on their own.

Do Bottlerocket and Talos publish SBOMs?

Yes. Bottlerocket images from v1.53.0 contain SPDX 2.3 and CycloneDX 1.6 SBOMs under /usr/share/bottlerocket/. Talos publishes SPDX SBOMs per architecture on each GitHub release and exposes them on a node with talosctl get sboms.

Is SELinux enforcing on Talos like on Bottlerocket?

No. Bottlerocket has run SELinux in enforcing mode since 0.3.0 with no way to turn it off. Talos added SELinux in 1.10 and ships it in permissive mode by default, because some CNI, CSI and extension combinations are not yet compatible; enforcing mode has been tested with the default Flannel CNI.

Rebuilding a container host fleet does not end supply chain exposure: every image you schedule onto those nodes pulls its own libraries, base layers and language packages, and the host OS itself is assembled from open source components that need version tracking. The honest limit is that fixes for Bottlerocket and Talos themselves come from their maintainers, so what follows applies to the software you build and run on top of them.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session. Safeguard is installed, safeguard opens the interactive terminal, and you ask it to "fix the lodash CVE in this repo." It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to the services you package as containers and schedule onto Bottlerocket or Talos nodes.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. A build or operations host that already downloads Talos release SBOMs or holds a Bottlerocket SBOM pulled from a canary node is a natural place to run those scans next to your image scans.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. For a platform team, that lets an assistant answer questions about your Safeguard data, such as which projects carry a given component version, only through the tools you allow.

Click through it at your own pace, or open it full screen.

To try it on your own repositories and images, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Bottlerocket repository README
• Bottlerocket CHANGELOG
• Bottlerocket releases
• Bottlerocket Security Features
• Bottlerocket Security Guidance
• Bottlerocket security advisories
• Bottlerocket update infrastructure (core kit updater README)
• Bottlerocket apiclient README
• Bottlerocket update operator (Brupop) README
• Bottlerocket docs, Updates overview
• Bottlerocket docs, Variants
• Bottlerocket docs, Guidelines for updating in place
• Bottlerocket docs, Locking to a specific release
• Bottlerocket docs, Chain of trust
• Bottlerocket docs, Reporting
• AWS Containers blog, Bottlerocket: a special-purpose container operating system (30 March 2020)
• AWS Open Source blog, General availability of Bottlerocket (31 August 2020)
• Amazon EKS user guide, Kubernetes version lifecycle
• Talos Linux repository
• Talos Linux releases
• Talos v1.14.4 release
• Talos v1.0.0 release
• Talos security advisories
• Talos docs, What is Talos Linux?
• Talos docs, Philosophy
• Talos docs, Support matrix
• Talos docs, What's new in Talos 1.14.0
• Talos docs, Upgrading Talos Linux
• Talos docs, Upgrading Kubernetes
• Talos docs, Image Factory
• Talos docs, System extensions
• Talos docs, SecureBoot
• Talos docs, Disk encryption
• Talos docs, SELinux
• Talos docs, Default hardening and CIS compliance
• Talos docs, Source Talos images
• Talos docs, SBOMs
• Talos docs, Subscribe to security advisories
• Talos docs, talosctl
• Talos docs, Debug shell
• Omni docs, Talos version support policy
• Kubernetes, Releases
• The Update Framework
• Kernel Self Protection Project
• Flatcar, Releases
• Flatcar docs, Supply chain security mechanisms
• Fedora CoreOS design document

Last reviewed: 24 October 2026.