$ whoami

I'm Martin Strhársky, a DevOps team lead in Slovakia. My team builds the platform a multi-team product estate ships on: pipeline templates, Terraform modules, shared GitHub Actions workflows, repository governance as code, and the identity and policy layer that keeps it all compliant. Mostly on Azure. The product teams mostly never think about any of it. That is the job done well.

The same standard shaped the work that got me here. Most of the last decade was migrations that were not supposed to be visible: Azure tenant moves, CI/CD swaps from TeamCity to Azure DevOps to GitHub Actions, a re-architecture onto a hub and spoke network under the Cloud Adoption Framework. None of them took a product down. That is a design outcome, not luck, and it comes from three boring questions: when to move, what to keep, and what the move costs. We kept Azure DevOps for pipelines longer than most teams would have, and moved to GitHub Actions only once our automation and policy story was mature enough to survive it. Enough of these by now that colleagues call me the migration specialist, a title nobody awarded and everybody uses.

Leading the team works the same way. Most of it is technical mentoring, so the engineers grow into people who make those calls themselves, rather than a queue I clear for them.

Away from the platform I go deep on AI tooling, for the same reason: I want the tools to run without my attention. Claude Code with hooks, custom workflows and feedback loops tuned to how I work. Every week I also work through architecture and leadership scenarios, the kind of decision that never arrives as a ticket.

What I have not settled yet: where Policy-as-Code stops scaling, how the platform has to change as the estate grows, and where AI earns a place in day-to-day DevOps work. Those questions are most of what I write about here.

If you are mid-migration, rethinking your platform's shape, or working out where AI belongs in your stack, write to me.

What I write about here

How I worked through a problem, and the reasoning behind what I chose. Not a prescription. Our constraints are not yours, and copying our answer into a different context usually goes badly. What travels is the thinking: what broke, what we tried, what it cost, and what I would look at first if I met it again.

Take it as inspiration and build your own version. If an article does not tell you what it cost, it is not finished.

Recurring themes: convention over configuration at org scale, keeping a large estate current without a full-time human on it, identity and tenant boundaries, and how to make an AI assistant trustworthy enough to delegate real work to.

Why this site exists

I have been writing and sharing for a while, in feeds and threads and other people's platforms. The goal has always been the same: if something took me two weeks to work out, writing it down might save somebody else the two weeks.

What was missing was a roof. Everything lives here now, in one place, in full, and it stays. Some pieces appear on LinkedIn too, and this is the copy that does not scroll away.

How it runs

This site runs on my own single-node k3s cluster on a Hetzner box. One repository builds the container image and holds what deploys it, Flux reconciles the cluster to match, Traefik and cert-manager serve it. Markdown in, website out, and no step in between that I cannot inspect.

That is more machinery than a static site needs, and that is the point. This is my playground for the things I do not touch daily at work, and for testing an idea before I recommend it to anyone. I would rather know how something behaves than know how it is supposed to behave, and I like automating things enough that the complicated path is the fun one.

Corrections are welcome and get credited. If an article is wrong, I would rather know.