<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Docker on Exygen</title><link>https://www.exygen.fr/en/tags/docker/</link><description>Recent content in Docker on Exygen</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Exygen</copyright><lastBuildDate>Mon, 15 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.exygen.fr/en/tags/docker/index.xml" rel="self" type="application/rss+xml"/><item><title>Building an in-house CI/CD platform: a field report</title><link>https://www.exygen.fr/en/blog/2026/06/15/selfhostedcicd/</link><pubDate>Mon, 15 Jun 2026 00:00:00 +0000</pubDate><guid>https://www.exygen.fr/en/blog/2026/06/15/selfhostedcicd/</guid><description>
&lt;p&gt;Running a dozen repositories and about twenty applications, libraries and websites quickly raises a simple but structural question: do you industrialize the build and deployment chain, or keep patching it together repo by repo? The choice made here was to design a self-hosted CI/CD platform, treated as a proper internal product — with its own design rules, auto-generated documentation, and its own lifecycle.&lt;/p&gt;
&lt;p&gt;An important clarification before going further: this platform isn't meant to be &amp;quot;better&amp;quot; than an established SaaS offering (GitHub Actions, GitLab CI, Bitbucket Pipelines...) in terms of features or operational comfort. It's a &lt;strong&gt;sovereignty&lt;/strong&gt; choice — keeping code, artifacts and build data under your own roof — accepted with its costs, and relevant above all for an organization that already has the in-house IT capacity to operate it over time. That point is developed further below.&lt;/p&gt;</description></item></channel></rss>