<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Container on The Coders Blog</title><link>https://thecodersblog.com/tag/container/</link><description>Recent content in Container on The Coders Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 05 May 2026 16:27:02 +0000</lastBuildDate><atom:link href="https://thecodersblog.com/tag/container/index.xml" rel="self" type="application/rss+xml"/><item><title>Docker 29: Understanding the New Default Image Store</title><link>https://thecodersblog.com/docker-29-default-image-store-changes-2026/</link><pubDate>Tue, 05 May 2026 16:27:02 +0000</pubDate><guid>https://thecodersblog.com/docker-29-default-image-store-changes-2026/</guid><description>&lt;p&gt;Your Docker deployments are about to get a lot more interesting, and potentially problematic, with the release of Docker Engine 29. This isn&amp;rsquo;t just another minor update; it’s a foundational shift that redefines where your container images and their layers live by default. If you&amp;rsquo;re managing infrastructure, direct Linux Docker Engine installs are now on a collision course with a significant backend change: the default image store is moving to containerd.&lt;/p&gt;</description></item></channel></rss>