I joined Mutual-IT within the Mutualités Libres last January. A clear observation quickly emerged: local development is currently carried out on environments that are often purely Windows-based, while test and production environments run on Linux.
This gap between the developer workstation and the target environment is a well-known source of deployment issues. In addition, developers’ code runs directly on Windows environments and is therefore subject—almost entirely—to the same security constraints as standard agents and users. This limits experimentation, testing, and the ability to evolve working methods.
The main friction probably lies in deployment itself: something works locally but not in ITT, UAT, or PRD—often due to configuration differences, memory settings, untested edge cases, or restricted access to configurations and locked environments.
To illustrate how to reduce this friction and move towards a declarative Infrastructure as Code approach—which aims to make local environments as close as possible to production—I developed a technical showcase available on GitLab: Docker Showcase Project
The idea is to get as close as possible to real-world conditions by simulating a modular hexagonal architecture across multiple containers.
The project is organized into four independent stacks:
- A PostgreSQL 15 database
- An API built with FastAPI and Python 3.11
- A server-side rendering (SSR) layer using Node.js 20
- An Nginx reverse proxy acting as a single entry point and managing API response caching
The key technical aspect lies in the use of a shared external network called showcase-net. This approach fully decouples the layers: only the proxy exposes a port to the host machine. The API and frontend remain isolated and communicate exclusively through the internal Docker network.
From my perspective, this configuration is particularly valuable because it prevents local port pollution and more accurately reproduces a Linux production environment—regardless of the developer’s operating system.
This approach is inspired by best practices that my team previously implemented during my time at RTBF, especially regarding strict CI/CD pipeline isolation and the simplification of development and deployment cycles. The goal is to ensure that the code running on a developer’s workstation is identical to what will be deployed.
To build this project, I used a toolchain based on local AI. The Gemma-4-31b model was run via LMStudio, integrated into VSCodium through the Cline extension. I had previously tested the integration between LMStudio and Continue, but the experience proved unstable (frequent issues interpreting certain tags and rapid degradation in response quality after a few prompts, making it difficult to use for extended sessions).
The VSCodium + Cline combination proved to be significantly more robust, precise, and stable.
This architecture is not intended as a purely theoretical exercise, but rather as a pragmatic, example-driven educational proposal to facilitate onboarding and harmonize development environments within Mutual-IT. The idea is that a simple shell script can install the entire infrastructure without any prior setup on the host system—except for Docker or Podman.
This serves as a foundation for discussion that I will share with my colleagues, with the aim of collaboratively defining standards that best suit our needs. It could even evolve into a hands-on workshop with structured steps (e.g., step-01, step-02, etc.), enabling feedback and building a shared understanding of container-based development models.
And you—how do you share your ideas and new concepts with your colleagues?