About Henrik Kiepe
I am a System Engineer working with Linux systems, infrastructure automation, networking and observability, with an emphasis on changes that can be verified and rolled back.
I work on Linux-based infrastructure, automation, networking and observability. This site documents how I investigate existing systems, change them safely and verify the result.
Who I am
My name is Henrik Kiepe. I am based in Cologne, Germany, and I currently work as a System Engineer at Next Kraftwerke. The company operates a Virtual Power Plant that connects and coordinates decentralised electricity producers, consumers and storage systems. Working in this environment reinforces something I consider fundamental: infrastructure is not merely the background on which a service runs. It is part of the service itself.
My professional work is centred on Linux-based systems and the operational practices around them. That includes infrastructure engineering, configuration management, automation, networking, DNS, reverse proxies, TLS, monitoring, observability, troubleshooting and the continuous improvement of systems that already exist. I work with technologies such as Linux, Ansible, Terraform and OpenTofu, Python and shell scripting, but I do not define good engineering by a list of tools.
My priority is to select technology that fits the actual problem, understand its trade-offs and use it effectively. A tool is valuable when it makes a system more reliable, understandable and maintainable. It becomes a liability when it adds complexity without creating a clear operational benefit.
A practical path into engineering
My path into infrastructure and operations includes studies at Paderborn University, entrepreneurship, web projects, software development and professional experience in Germany and Poland. I have continued to broaden that experience through training in networking, Python, web development and configuration management.
Earlier entrepreneurial work taught me to think beyond implementation. When you are responsible for a complete service or business, technical decisions are inseparable from maintenance, cost, security, communication and the experience of the people who depend on the system. That sense of ownership still shapes how I work today.
I am comfortable working across German, English and Polish contexts. This website is written primarily in English because infrastructure problems rarely stop at national borders, and because I want the material to be useful to a wider technical community.
How I approach operations
Before changing a system, I want to understand its current state: which components are involved, what depends on them, how the existing behaviour can be observed and what a safe recovery path looks like. I prefer small, reviewable changes over interventions whose effects are difficult to isolate.
Automation is an important part of my work, but automation is not a goal in itself. An unclear manual process does not become a good process simply because it is expressed in code. Useful automation should make work repeatable, testable and easier to review. It should behave predictably when it is run more than once, expose failures clearly and avoid silently replacing decisions that still require human judgement.
The same applies to monitoring and documentation. A dashboard is useful only when its signals help someone understand the condition of a service. Documentation is useful only when another person can use it to make a sound decision. Both belong to the system's operational design; neither should be an afterthought added shortly before handover.
Verification matters as much as implementation. A successful command, deployment or automation run does not prove that the complete service works. DNS may return the expected address while a local resolver, firewall, reverse proxy, certificate or application still behaves incorrectly. A configuration may be syntactically valid while changing behaviour in an unintended way. I therefore try to verify the complete path that users and dependent systems actually rely on.
Why this website exists
ops.kiepe.dev is my personal technical workbench and public knowledge base. I use it to turn operational experience, troubleshooting, experiments and project work into material that others can review and reuse.
Rather than reproduce reference manuals or publish commands without context, I focus on the operational questions around them: why a sequence of checks is useful, which assumptions a solution depends on, what can fail, how a change can be introduced safely and how to verify the result. The perspective is that of someone who has to operate the system after the example ends.
Real systems contain history, dependencies, manual changes, incomplete documentation and constraints that are not visible in a clean example. I want the material here to acknowledge that reality, not merely demonstrate that a configuration can be created.
The site is for Linux administrators, system and platform engineers, developers with operational responsibilities and people running their own infrastructure. It is also a record for my future self: a place to preserve decisions that would otherwise disappear into terminal history, ticket comments or private notes.
What you will find here
The main subjects are Linux system administration, infrastructure and platform engineering, configuration management with Ansible, infrastructure as code with Terraform and OpenTofu, DNS, TLS, networking, NGINX and reverse proxies, monitoring and observability, security-conscious operations, automation with Python and shell tools, homelab experiments and the design of small operational tools.
- Articles: Detailed explanations of operational topics, technical decisions and complete workflows, including context, risks and verification.
- Notes: Shorter checks, commands, troubleshooting sequences and practical reminders that are useful during day-to-day operations.
- Projects: Documentation of systems and tools I build, operate or improve, including their current state, limitations and next steps.
- Topics: Thematic paths through the site for areas such as Linux operations, automation, observability, infrastructure as code and security-conscious infrastructure.
Some entries describe solutions that worked well. Others examine mistakes, unexpected behaviour or an approach that had to be revised. I consider both useful. Engineering knowledge becomes more trustworthy when it includes uncertainty, constraints and failed paths instead of presenting every outcome as obvious in retrospect.
The website is also a project
This site is not only a place where I publish technical work; it is itself part of that work. I am developing a file-first content platform that treats technical publishing with the same care I expect from infrastructure: source-controlled content, explicit review, validation, reproducible builds and deliberate deployment.
That approach helps me keep private ideas separate from public material, check content before it crosses the publication boundary and make the website maintainable without depending on a large content-management system. It also gives me a practical environment in which to explore Rust, static-site generation, deployment checks and editorial workflows.
Selected technical work
Alongside my main employment, I take on selected personal, voluntary and freelance projects when they are compatible with my responsibilities. The best fit is work where an existing system needs to be understood before it can be changed safely.
The common thread is existing infrastructure that needs to become easier to understand and operate: a service brought under configuration management, a migration split into reviewable steps, or an explicit deployment and recovery path. I publish lessons from this work when doing so does not expose confidential or sensitive information.
One current example is my voluntary support for Heiner Flassbeck and Relevante Ökonomik and the follow-up account of its infrastructure and controlled modernization.
If you want to discuss a specific system or project, email me at mail@hkiepe.de or contact me on LinkedIn. I can then assess whether the work fits my experience and existing responsibilities.
Beyond technology
One of my favourite hobbies is dancing Brazilian Zouk. I enjoy its combination of movement, music, connection, communication and improvisation. I also practise Qigong, which gives me a quieter way to work with attention and balance.
I enjoy spending time outdoors, travelling and discovering new places. Time with my family and the people close to me remains one of the most important parts of my life.
You can browse the latest articles, follow new material through the RSS feed, or use the topic pages to follow a particular area.
Personal publication notice: This is a personal and independent website. The views expressed here are my own and do not represent Next Kraftwerke or any other organisation with which I work. Technical examples are generalised and should be evaluated in the context of your own systems and requirements.