<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>DevOps on Thyago Seugling</title><link>https://thyago.link/tags/devops/</link><description>Recent content in DevOps on Thyago Seugling</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 08 Feb 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thyago.link/tags/devops/index.xml" rel="self" type="application/rss+xml"/><item><title>The Art of the Minimal Docker Compose Stack</title><link>https://thyago.link/blog/docker-compose/</link><pubDate>Sun, 08 Feb 2026 00:00:00 +0000</pubDate><guid>https://thyago.link/blog/docker-compose/</guid><description>&lt;p&gt;I&amp;rsquo;ve seen compose files that span three hundred lines, define seventeen networks, and require a dedicated README just to explain the environment variables. I&amp;rsquo;ve also written a few of them. That era is over. Every stack I deploy now follows a small set of principles that I&amp;rsquo;ve refined through a lot of painful rollbacks.&lt;/p&gt;
&lt;h2 id="the-problem-with-bloat"&gt;The Problem with Bloat&lt;/h2&gt;
&lt;p&gt;Configuration drift is silent and cumulative. A commented-out service here, an undocumented environment variable there — and six months later, no one (including you) knows what&amp;rsquo;s load-bearing and what&amp;rsquo;s vestigial. The compose file stops being documentation and becomes archaeology.&lt;/p&gt;</description></item></channel></rss>