Linux security · Denmark
Secure Linux,down to the kernel.You own all of it.
I help companies that run their own Linux servers detect attacks, harden their fleets and fix critical CVEs quickly. Everything I build stays in your repository, under your licence. It keeps working after our engagement ends.
- 600+
- Linux servers run across my career
- 30+
- Clients since 2018
- 1 business day
- Reply to every email
git clone git@your-org:infra.git
Cloning into 'infra'… done.
tofu plan -out=tfplan
Plan: 12 to add, 3 to change, 0 to destroy.
helius handover --verify
runbooks ok
licences ok
vendor lock-in none
Services
Four ways I can help
Two services secure your Linux servers, down to the kernel. Two make the platform on top of them faster and easier to run. Most engagements touch more than one.
Kernel & Linux
Kernel security
Kernel & Linux
Linux hardening
Platform
Performance
Platform
Infrastructure
Under the hood
The whole stack, and who owns each layer
This is roughly what I build and operate, from the public edge down to the kernel. Every layer is open-source software running on infrastructure you own. Select a layer to see what goes in it.
Edge
Where traffic arrives. Automatic certificate renewal that nobody has to remember, DNS in code alongside everything else, and caching rules that are reviewed rather than accumulated.
- Nginx
- OpenResty
- HAProxy
- CoreDNS
- cert-manager
Ingress & mesh
Routing into the cluster and between services, with mutual TLS by default and traffic-shifting that makes canary deploys possible. Policy lives in version control, not in a console.
- Traefik
- Envoy
- Cilium
- Gateway API
- nftables
Orchestration
Where workloads get placed and how they roll out. Sized to your actual load — sometimes a full cluster, sometimes three machines and a load balancer, and I will tell you honestly which one you need.
- Kubernetes
- Argo CD
- Helm
- Kustomize
- k3s
Runtime
Your application and the stateful things it depends on. Containers built reproducibly, databases with tested backups, and connection limits set from measured behaviour rather than defaults.
- containerd
- MySQL
- Percona
- PostgreSQL
- Redis
Kernel & eBPF
The layer most stacks treat as a black box, which is precisely the problem. eBPF lets you watch process and syscall activity from inside the kernel without a proprietary agent, and LSM and kprobe hooks let you cut attack surface at the source rather than filtering after the fact. This is where I spend most of my time.
- eBPF
- aya
- bpftrace
- LSM
- kprobe
- nftables
- SELinux
Telemetry
Everything above emits here, and this is what you look at during an incident. Correlated signals, alerts tied to user-visible symptoms, and retention tuned so the bill stays predictable.
- Zabbix
- Prometheus
- Grafana
- Loki
- OpenTelemetry
- Alertmanager
My pledge
I deliver, you own 100%
This is the part of the site I would most like to be judged on. Each of these is a specific, checkable commitment rather than a value statement — if I break one, you can point at it.
Everything in your repository
Pipelines, manifests, Terraform, dashboards, alert rules, runbooks. Committed to repositories you own, under a licence you pick. Nothing lives only on my machine or in an account I control.
Open-source components only
Every tool I put into production is open source and self-hostable. Where a managed service genuinely is the right answer, I say so and you decide — but the default is software you can read.
No metering, no seats, no hosts
I charge for days worked. Nothing I build bills you for growing, and no component sends data back to Helius or counts your servers.
Handover is included
Documented architecture with the reasoning, runbooks per alert, and a working session where your team drives. Not an upsell, not a final invoice line.
The exit clause
You can end the engagement at any time. There is no notice period, no exit fee and no migration project. Everything keeps running, because none of it needs me to run.
Upstream where it helps
Fixes and tooling that are generally useful go back to the projects they came from, or get released standalone — with your permission, and never containing anything of yours.
Latest writing
Working notes
The blog is where the reasoning behind most of the opinions on this site lives — kernel debugging, Rust, infrastructure post-mortems. It runs on MkDocs at /blog and is written in English.
Frequently asked
Common questions before hiring me
Including price, and how to end the engagement.
How do engagements usually work?
Most clients start with a Linux security review: 3 days for up to 10 servers, EUR 4,800 excl. VAT, ending in a written report you keep. If you continue, I credit the fee against the next project. After that it is either a fixed-scope project with a written quote, or a retainer for an agreed number of days a month. I do not take open-ended time-and-materials work without a scope, because it is bad for both of us.
Can you work with our existing team and tools?
Yes, and that is usually the point. I am not interested in replacing a working setup for the sake of my preferences. If you already run GitLab, or Nomad instead of Kubernetes, or a managed database, we work with it. I will tell you plainly if I think something is a genuine liability, and then it is your call.
Who owns the code and configuration you write?
You do, entirely. Everything lands in your repositories under a licence you choose. Nothing I deliver is a closed product: no proprietary agent, no control plane, no component that stops working if you stop paying me. Blackbox Linux, my own open-source agent, is never a condition of an engagement. If a piece of your work is generally useful, I may ask to release it as open source separately. That is a request, never a condition.
Why only open-source tooling?
Because I have been on the wrong end of the alternative. Closed agents you cannot audit, per-host pricing that punishes you for growing, and vendors who change the licence once you are committed. Open-source components mean you can read what runs on your servers, host it yourself, and replace me without replacing your stack.
Do you take on-call or 24/7 support?
Not as a primary on-call rotation — I am one person, and pretending otherwise would be dishonest. What I do is build the alerting and runbooks so your own team can handle on-call alerts with confidence, and act as an escalation contact during agreed hours on a retainer.
What access do you need, and what happens to it afterwards?
The least that lets me do the work — usually a named account with scoped permissions, never a shared root credential. Access is revoked at the end of the engagement and I will remind you if you forget. I do not copy production data to my machine; if I need realistic data for testing we generate or anonymise it.
What does it cost?
Your first email and my reply are free. The Linux security review has a fixed price of EUR 4,800 excl. VAT; if it takes longer, that is my cost. Larger projects are quoted in writing at a day rate of EUR 1,600 excl. VAT, and you approve the quote before any work starts. Email me a rough description and I will reply with a price and an estimate of how many days it takes.
How do we end it?
You say so. There is no notice period and no exit fee. Handover is part of every engagement, not an upsell: documented architecture, runbooks, and a session where your team drives while I answer questions. The test is whether everything still runs a month after I stop. It does, because none of it depends on me.
Tell me what is broken
A short description is enough. Within one business day I will tell you what I think the problem is, roughly how long it takes, and whether you need me at all. Sometimes the honest answer is no.