flatcar · tormath1 · Jan 7, 2026 · Jan 6, 2026 · Jan 6, 2026
@@ -14,8 +14,7 @@ For switching to using containerd with Kubernetes, there is an [extra guide](../
 
 ## Use a custom containerd configuration
 
-The default configuration under `/run/torcx/unpack/docker/usr/share/containerd/config.toml` can't be changed but you can copy it to `/etc/containerd/config.toml` and modify it.
-**NOTE** that newer Flatcar major releases (above major release version 3760) ship the default configuration under `/usr/share/containerd/config.toml`.
+The default configuration under `/usr/share/containerd/config.toml` can't be changed but you can copy it to `/etc/containerd/config.toml` and modify it.
 
 Create a `/etc/systemd/system/containerd.service.d/10-use-custom-config.conf` unit drop-in file to select the new configuration:
 

@@ -358,10 +358,6 @@ to the following directories on the host file system:
 - `/var/lib/containerd/`
 
 And that it has access to the following binaries on the host file system and that they are included in `PATH`:
-- For Flatcar releases until major version 3760:
-  - `/run/torcx/unpack/docker/bin/containerd-shim-runc-v1`
-  - `/run/torcx/unpack/docker/bin/containerd-shim-runc-v2`
-- For Flatcar releases above major version 3760:
   - `/usr/bin/containerd-shim-runc-v1`
   - `/usr/bin/containerd-shim-runc-v2`
 

@@ -157,7 +157,7 @@ For DHCP you don't need to specify any networkd units.
 After transpilation, the resulting JSON content can be used in `guestinfo.ignition.config.data` after encoding it to base64 and setting `guestinfo.ignition.config.data.encoding` to `base64`.
 If DHCP is used, the JSON file can also be uploaded to a web server and fetched by Ignition if the HTTP(s) URL is given in `guestinfo.ignition.config.url`.
 
-Beginning with Flatcar major version 3248, fetching remote resources in Ignition or with torcx is not only supported with DHCP but also by using `guestinfo.afterburn.initrd.network-kargs` to define a custom network configuration, here an [example for a static IP address](https://coreos.github.io/afterburn/usage/initrd-network-cmdline/#vmware).
+Beginning with Flatcar major version 3248, fetching remote resources in Ignition is not only supported with DHCP but also by using `guestinfo.afterburn.initrd.network-kargs` to define a custom network configuration, here an [example for a static IP address](https://coreos.github.io/afterburn/usage/initrd-network-cmdline/#vmware).
 
 IP configuration specified via `guestinfo.interface.*` and `guestinfo.dns.*` variables is currently not supported with Ignition and will only work if you provide coreos-cloudinit data (cloud-config or a script) as userdata.
 

@@ -1,13 +1,14 @@
 ---
-title: Container Linux Config Transpiler
-linktitle: Container Linux Config Transpiler
+title: "[DEPRECATED / EOL] Container Linux Config Transpiler"
 description: YAML configuration format used to generate Ignition configs.
 weight: 20
 aliases:
     - ../os/provisioning
     - ../reference/migrating-to-clcs/provisioning
 ---
 
+:warning: TL; DR: Use [Butane](../config-transpiler). While Flatcar does support both Ignition spec version (2.x and 3.x), we encourage folks to use [Butane](../config-transpiler) first but we still maintain / document backward compatibility for users who still rely on Ignition 2.x. :warning:
+
 Flatcar Container Linux automates machine provisioning with a specialized system for applying initial configuration. This system implements a process of (trans)compilation and validation for machine configs, and an atomic service to apply validated configurations to machines.
 
 ## Container Linux Config

@@ -19,7 +19,7 @@ The resulting Ignition config is very much not intended to be human-friendly. It
 [butane]: https://github.com/coreos/butane/
 [ignition]: https://github.com/coreos/ignition
 
-**Note:**: Butane is utilized to generate Ignition v3+ configurations. If you are still utilizing a version of Container Linux that requires Ignition v2, you can refer to the [Container Linux Config Transpiler][cl-config] documentation. This particularly applies to those using the current LTS releases.
+**Note:** Butane is utilized to generate Ignition v3+ configurations. If you are still utilizing a version of Container Linux that requires Ignition v2, you can refer to the [Container Linux Config Transpiler][cl-config] documentation.
 
 ## Why a two-step process?
 

@@ -6,7 +6,6 @@ weight: 39
 
 Flatcar Container Linux bundles various software components with fixed versions together into one release.
 For users that require a particular version of a software component this means that the software needs to be supplied out of band and overwrite the built-in software copy.
-In the past Torcx was introduced as a way to switch between Docker versions.
 Another approach we recommended was to [store binaries in `/opt/bin`](../../container-runtimes/use-a-custom-docker-or-containerd-version/) and prefer them in the `PATH`.
 
 For long time already, the systemd project provided the portable services feature to address deploying custom services.
@@ -20,11 +19,6 @@ Here's some blog posts you can read for more context:
 2. https://www.flatcar.org/blog/2023/07/summer-2023-my-internship-experience/
 3. https://www.flatcar.org/blog/2023/12/extending-flatcar-say-goodbye-to-torcx-and-hello-to-systemd-sysext/
 
-## Torcx deprecation
-
-Since systemd-sysext is a more generic and maintained solution than Torcx, it replaced Torcx since Flatcar version 3794.0.0 and the last major version to include Torcx was 3760.
-Any Torcx usage should be migrated by converting your Torcx image with the `convert_torcx_image.sh` helper script from the [`sysext-bakery`][sysext-bakery] repository, mentioned later in this document. The inbuilt Docker and containerd versions can be disabled which is also showed further below.
-
 ## Types of systemd-sysext images
 
 For Flatcar, two types of systemd-sysext images are provided:
@@ -120,7 +114,7 @@ Upholds=docker.socket
 ## Supplying your sysext image from Ignition
 
 The following Butane Config YAML can be be transpiled to Ignition JSON and will download a custom Docker+containerd sysext image on first boot.
-It also takes care of disabling Torcx and future built-in Docker and containerd sysext images we plan to ship in Flatcar (to revert this, you can find the original target of the symlinks in `/usr/share/flatcar/etc/extensions/` - as said, this is not yet shipped).
+It also takes care of disabling built-in Docker and containerd sysext images (to revert this, you can find the original target of the symlinks in `/usr/share/flatcar/etc/extensions/`).
 
 ```yaml
 variant: flatcar
@@ -131,7 +125,6 @@ storage:
       mode: 0644
       contents:
         source: https://myserver.net/mydocker.raw
-    - path: /etc/systemd/system-generators/torcx-generator
   links:
     - path: /etc/extensions/docker-flatcar.raw
       target: /dev/null
@@ -169,17 +162,6 @@ To ease the process, the [`create_docker_sysext.sh`](https://raw.githubuserconte
 [… writes mydocker.raw into current directory …]
 ```
 
-## Converting a Torcx image
-
-In case you have an existing Torcx image you can convert it with the [`convert_torcx_image.sh`](https://raw.githubusercontent.com/flatcar/sysext-bakery/main/convert_torcx_image.sh) helper script (Currently only Torcx tar balls are supported and the conversion is done on best effort):
-
-```
-./convert_torcx_image.sh TORCXTAR SYSEXTNAME
-[… writes SYSEXTNAME.raw into the current directory …]
-```
-
-Please make also sure that your don't have a `containerd.service` drop in file under `/etc` that uses Torcx paths.
-
 ## Updating custom sysext images
 
 From Flatcar 3510.2.0, it is possible to use the `systemd-sysupdate` tool that covers the task of downloading newer versions of your sysext image at runtime from a location you specify.