👋 Welcome to Eliorion’s blog

Introduction I’ve built many projects on my own, but I never shared them publicly. For a long time, I wanted to have my own server with a personal domain name. Unfortunately, for personal reasons, I couldn’t maintain a persistent server. Recently, I discovered a solution that lets me host a blog within minutes using Hugo and GitHub — so here I am. My Linkedin You can see my Linkedin if you want.

The Goal: A Reproducible Server The worst kind of infrastructure is a server that nobody fully understands anymore. Things were installed over time, configuration changed in place, and the mental model of how it all fits together lives only in the memory of whoever last touched it. If that server dies, rebuilding it requires archaeology. The goal for mve-itguard was the opposite: a fresh Debian machine should go from zero to fully operational — users created, Docker installed, runners running, services ready to deploy — with a single command that anyone with the repository and the AGE key can run. ...

The Problem Every Project Has Every project that deploys to a real server has secrets. Tokens, passwords, API keys — values that should not be publicly visible but that the application needs to run. The GitOps approach makes this harder to ignore. If Git is the single source of truth and all configuration lives in the repository, where do the secrets go? Committing them in plaintext is an obvious mistake. Leaving them outside Git means the repository is no longer the complete source of truth — some knowledge lives only in someone’s head or in a separate system. ...

GitOps Is a Principle, Not a Tool When people talk about GitOps, Kubernetes quickly enters the conversation. FluxCD, ArgoCD, Helm — the ecosystem is rich, and the tooling handles a lot of the heavy lifting. The platform continuously watches the repository and reconciles the cluster state to match what Git declares. But the underlying principle has nothing to do with Kubernetes specifically. GitOps is simpler than that: Git is the single source of truth. No change happens outside of Git. Automation applies what Git declares. ...

The Problem with Commercial Solutions When I started thinking about home security cameras, the obvious path was a commercial solution — Ring, Nest, or one of the dozens of cloud-connected systems on the market. Plug it in, create an account, and you’re done. I did not go that route. Not because it is difficult to set up, but because of what it implies: your video footage lives on someone else’s server, your access depends on a subscription, and if the company changes its pricing or shuts down, you lose everything you built around it. ...

Fist conplete containerise Python application In the context of the KubeCraft course, I needed to create a complet containerise Python application from scratch. The course is focus on the DecSecOps implementation, note the Python part. Pre-require The first step to have a nice DevSecOps environnement is the team work. I will be the only one who use this project, but in reality a hole team will need to have access and modify some piece of the application. First think in mind when you have IT project and team work, you think about Git. Even you haven’t a team to work with, use Git is a nice way to have log of your work and explain why the application don’t work after a modification, and be able to come back to a secure version. ...

KubeCraft Course After completing the first Kubernetes course, where I deployed a basic K3s cluster on Rancher Desktop, I moved to the next level: a homelab course focused on building a fully GitOps-based K3s cluster on a Debian VM, hosting real self-hosted applications exposed to the internet. What to Expect at the End? The final goal is to deploy a self-hosted Linkding application accessible from the internet using a custom domain name. ...

When 2 GB of RAM Broke My Dev Environment One of my first real breakthroughs in learning Linux happened when I started working seriously with containers. At first, I struggled with the Docker CLI. It felt abstract and sometimes unintuitive. But the more I learned about Linux — processes, namespaces, cgroups, filesystems — the more containers started to make sense. Containerization is not magic. It is Linux. Understanding that changed everything. ...

Why I needed to step back It’s been a month since I subscribed to the KubeCraft Career Accelerator program. I quickly realized how lost I was when it came to Linux basics, especially everyday usage and command-line fundamentals. I used to develop on embedded Linux systems, but I was probably using only 10% of the real power of the Linux CLI. So I decided to become a beginner again and truly master the Linux command line first, using the full development process directly in the terminal. The goal is to become extremely strong on the fundamentals so that, in a few months, I’ll be able to learn anything using only a terminal, and manage or administer any Linux server anywhere in the world with just a basic shell and bash. ...

My First Homelab (for the second attempt) This homelab is the first real infrastructure I’m building—although technically, it’s already my second attempt. Why a Second Attempt? The first time I tried to set everything up, I used Proxmox running on a VM provider and Talos Linux for my Kubernetes nodes. I experimented with countless configurations, trying to understand how Talos works behind the scenes. Each time a node failed or something didn’t behave the way I expected, I had to rebuild everything manually, one node at a time. It was painful, slow, and sometimes discouraging… but I learned a lot from it. ...