Services
Each line above is one of the sections below, in order — the same seven entries the services menu carries. Follow a line to jump to its section; each section then links out to the page that covers it in full.
Infrastructure as Code & DevOps
I use NixOS because it turns an operating system into version-controlled code — every service, every config, every package declared in a file instead of installed by hand. Where a stack already exists, the same discipline carries to Ansible and Terraform.
What that looks like in practice:
- The whole host declared in one repository, with a module shared by every machine
- Services, web servers, databases and monitoring declared rather than configured in place
- Changes deployed from a reviewed commit, with each generation built before it is switched to
- Atomic upgrades, and a rollback that takes seconds instead of a restore from a backup
The thing I actually want out of this is the rollback. If a deploy breaks a service, the machine goes back to the generation that worked while we work out why — which is why I would rather show you the health gate that fires it than quote you an uptime number I cannot back.
Read more: Infrastructure as Code & DevOps →
Cloud Infrastructure
I’ve worked on AWS production infrastructure for over a decade, including 5 years hosting one of the world’s top 500 websites, or ranked ~130-140 in the US, with only a handful of other people.
What I do:
- Design the architecture around the workload rather than around one provider’s feature list
- Size instances to real traffic and its failure budget instead of a guessed instance class
- Keep compute, network, DNS, storage and secrets portable between providers
- Plan the backups and the recovery path, then test that the restore actually works
Portability matters because the bill and the vendor can both change without a rewrite. There is nothing wrong with paying for quality and plenty wrong with paying for waste, so every important line on the bill should trace back to a workload.
Read more: Cloud Infrastructure →
Security Engineering
My entire fleet runs through a WireGuard VPN with encrypted DNS. Nothing is reachable from the internet except the one public web host, which opens only 80/443 and the TURN ports. Everything else is routed through the VPN tunnel. ISPs can’t see what sites you visit. Governments and corporations can’t easily profile your DNS queries against existing profiles of you.
What I do:
- WireGuard deployments with key material handled explicitly
- Encrypted resolvers inside the tunnel, so queries are not visible to the local network
- Firewall rules sized to the surface you actually need to expose
- SSH hardened to keys and one known path in
- SPF, DKIM and DMARC so your domain’s mail can be authenticated
I’m not going to call a network “zero-trust” and leave it there. The phrase only means something once you can list what is reachable from where and by whom — so that list is part of the deliverable, and it is short on purpose.
Want this for yourself rather than for a company? The consumer VPN service — WireGuard with a choice of DNS posture — is at VPN Service.
Read more: Security Engineering →
Monitoring & Observability
I set up metrics, logs, dashboards and alerts together, because the point of all of it is to find out something broke before your users tell you.
What I do:
- Metrics — storage sized for host and service telemetry, with the queries you actually run
- Logs — centralized collection and search across the fleet
- Dashboards — built around the questions your team asks, not around every available panel
- Uptime monitoring — external checks for endpoints, certificates and critical paths
- Alerting — notifications through Telegram, Discord, Slack or email, each with its runbook
An alert is only worth having if it is actionable. A page that fires every time a disk crosses 80% trains people to ignore pages, so I would rather tune a threshold until it fires when the thing it protects is actually broken — and prove it by making it fire once.
Read more: Monitoring & Observability →
Email Infrastructure
Hosting your own email is more straightforward than most people think, and it is mostly a matter of getting every hand-off right: submission, authentication, filtering, delivery, and the bounce path back.
What I do:
- Postfix and Dovecot on a maintained stack, with authenticated submission over TLS
- SPF, DKIM and DMARC, plus the reports that let the policy be tightened from evidence
- Spam and virus filtering, with explicit message-size and connection limits
- Bounce handling, quota policies and aliases
- Webmail, or a documented path for the client you already use
Your mailbox data stays on infrastructure you control, with no per-user licence layered on top of it. If deliverability is the worry, that one is measurable — I would rather measure it than promise it.
Read more: Email Infrastructure →
VPN & Encrypted Networks
The tunnel I run for myself is the same one I design for organizations: WireGuard links between sites, clouds and individual hosts, with DNS resolved inside the tunnel and administrative access reachable only from within it. The public surface stays as small as the workload allows.
What I do:
- Site-to-site and host-to-site tunnels with key material handled explicitly
- Remote access for people, devices and contractors without opening an admin port
- Encrypted resolvers inside the tunnel, so queries are not visible to the local network
- Firewall and routing design with the internet-facing surface reduced to what is deliberate
- Split-tunnel or full-tunnel policy chosen per device rather than per vendor default
You end up with a network nothing can reach until a device is joined to it, DNS your provider cannot profile, and administrative paths no scanner will find because nothing is listening publicly. The configuration is written down and handed over, so the next engineer can read it.
For one person rather than an organization, the consumer service is at VPN Service — the tiers and the argument behind them are in the technical dossier.
Read more: VPN & Encrypted Networks →
Consulting & Audit
Not ready to commit? Start with an audit. This is a scoped, one-off review of the state of your stack: what you actually run, what is exposed, what is not enforced the way you think it is — delivered as a written report where every finding is reproducible, not a score out of ten.
What I do:
- An inventory of what is really running — hosts, services, ports open to the internet, DNS, mail, backups
- A security review: firewall rules, SSH access paths, TLS, authentication, secret handling
- A configuration review against your declarative source (NixOS, Ansible, Terraform) — or against the live state, if there is no source to read
- The logging posture, checked behaviourally rather than read off a config file: re-apply the setting, send a probe, then look for what was written
- Performance and cloud-spend findings, each with the number that justifies it
- Findings ranked by what to fix first, with the evidence for each attached
You get a report you can hand to your own team or your board, because each finding can be re-run, and a remediation roadmap scoped to your budget rather than a wishlist. There is no sales pitch attached to it: the deliverable is the document, whether or not you hire me to do the fixing.
What it is not. It is not a certification audit and not an independent opinion. I am one engineer giving you an assessment of your own infrastructure; nothing in the report implies an accredited certification or a third-party attestation, and it will state which areas were checked and which were not. The vocabulary this site permits itself around certifications is set out on Standards & Claims.
The audit I run on my own fleet daily — invariant checks, an ed25519-signed report per host, published keys, monthly roll-ups that freeze once closed — is described at Infrastructure Audit. A client engagement normally stops well short of that, but it is the same method and the same standard of evidence.
Read more: Consulting & Audit →