Advice shaped by running the systems.
RTFM d.o.o. is my practice. I’m Matija Žeželj, an infrastructure and security engineer with more than twenty years of hands-on experience designing, scaling, and defending production systems.
I have run Linux fleets of thousands of servers, operated more than forty bare-metal Kubernetes clusters, and built security automation across an engineering estate of over a thousand repositories: SBOM and vulnerability pipelines, runtime detection, workload identity, and the SIEM that ties them together. The common thread is making systems legible to the people who have to run them.
It is one person, and that is deliberate. The engineer who reads your environment is the one who writes the decision record, deploys the blueprint, and answers during the response window.
The In a Box projects come directly out of that work.
Operating principles
Local by default
Telemetry, asset graphs, identities, vulnerability findings, certificates, and compliance evidence stay on infrastructure you control. Cloud integrations are optional, never the price of entry.
Honest boundaries
This work reduces integration toil. It does not replace capacity planning, backups, threat modeling, incident responders, or knowing your environment. When a tool is an IDS rather than an inline IPS, the documentation says so.
Knowledge transfer is part of the deliverable
Documentation and handover are included in every engagement. A dependency on the consultant is a failure mode, not a business model.
Why “RTFM”
Because the manual is usually the thing nobody wrote. The engagements that go well are the ones that leave behind a written decision record, a runbook that matches reality, and evidence that recovery actually works — so the next person to touch the system has something to read.
Elsewhere
- In a Box Tools — product documentation, demos, and the project blog
- GitHub — source for the published blueprints
- LinkedIn — background and work history