About
About Henrik Kiepe and this personal operations website.
Who I Am
I am Henrik Kiepe, a Linux systems administrator and platform engineer based in Cologne, Germany.
My work sits at the intersection of Linux operations, infrastructure engineering, automation and software development. I am particularly interested in systems that remain reliable, understandable and maintainable long after their initial deployment.
My technical focus includes Linux, Ansible, Terraform and OpenTofu, Python, DNS, networking, monitoring and observability. I work on the operation and continuous improvement of infrastructure, automate recurring processes and investigate problems across different layers of a system.
For me, infrastructure work is not simply about keeping servers online. It is about understanding how systems behave, identifying the actual cause of problems and making changes in a controlled and reproducible way. Good operations should reduce uncertainty rather than hide complexity behind another tool.
I therefore try to approach technical problems methodically: observe first, understand the dependencies, make the smallest reasonable change and verify the result across the complete path.
Why This Website Exists
This website is my personal space for writing about Linux, infrastructure and operations.
I use it to document what I learn through practical work, personal projects, experiments and troubleshooting. It is intended to be a combination of a technical notebook, a knowledge base and a transparent record of how I approach infrastructure problems.
The content is divided into several formats:
Articles provide detailed explanations of operational topics, technical decisions and complete workflows. Notes contain shorter commands, observations, troubleshooting sequences and practical reminders. Projects document systems and tools that I am building, operating or improving. Topics make it possible to follow specific areas such as Linux operations, automation, observability or infrastructure as code.
I do not want to reproduce generic documentation that already exists elsewhere. Instead, I want to concentrate on the parts that are often missing: the reasoning behind a solution, the order in which checks should be performed, the risks involved in a change and the methods used to confirm that a system is actually working.
A successful command is not always proof that the complete service works. A DNS query may return the expected address while a local resolver, reverse proxy, TLS certificate or application still behaves incorrectly. An automation run may complete without errors while unintentionally overwriting an important manual configuration.
These practical details are where a large part of real infrastructure work takes place.
What I Write About
The main subjects on this website include:
Linux system administration and troubleshooting Infrastructure and platform engineering Configuration management with Ansible Infrastructure as code with Terraform and OpenTofu DNS, TLS, networking and reverse proxies Monitoring, metrics and observability Reliable and security-conscious operations Automation with Python, shell scripting and other tools Homelab projects and technical experiments The design and development of operational tools
I also document selected personal, voluntary and freelance projects when they provide useful technical lessons. These projects often connect infrastructure engineering with web publishing, content workflows and the long-term maintenance of independently operated platforms.
Some articles will describe solutions that worked. Others will examine mistakes, unexpected behaviour or approaches that had to be revised. Both are valuable. Engineering knowledge becomes more useful when it includes the constraints, assumptions and failed paths—not only the final configuration.
How I Think About Automation
Automation is an important part of my work, but I do not consider automation a goal in itself.
A process should be automated when doing so makes it more consistent, testable, repeatable and easier to maintain. Automating an unclear process can simply reproduce mistakes faster and on a larger scale.
Before automating something, I therefore try to understand its current state, dependencies and possible failure modes. The resulting automation should be readable, reviewable and safe to run more than once. Wherever possible, it should also provide clear validation and a realistic path back when something goes wrong.
Documentation belongs to the same process. Infrastructure that only one person understands is difficult to operate reliably, regardless of how technically sophisticated it may be.
Beyond Technology
Technology is an important part of my life, but it is not the only one.
One of my favourite hobbies is dancing Brazilian Zouk. I enjoy the combination of movement, music, communication and improvisation. I also practise Qigong, which helps me develop focus, awareness and balance.
Sport and physical activity are important to me in general. I like spending time outdoors, discovering new places and staying active rather than sitting in front of a screen all the time.
I also enjoy travelling and experiencing different countries, cultures and ways of life. At the same time, spending time with my family and the people close to me remains one of the most important parts of my life.
These interests may appear far removed from Linux operations, but they influence how I work. Curiosity, patience, adaptability and attention are useful both when understanding another person and when understanding a complex technical system.
An Evolving Record
This website will continue to grow alongside my experience and projects.
It is not intended to present a polished image in which every system works immediately and every decision is obvious. It is a practical and evolving record of what I build, what I learn and how I think about reliable infrastructure.
My aim is to create material that is useful to other engineers, helpful to my future self and transparent enough to show not only what I do, but also why I do it that way.