Capabilities
What we can build for you, and the evidence that it works.
10 pieces of work that can be bought as they stand. Each one says what gets built, what you are handed at the end, and where its numbers came from: 7 from a live estate, 2 from a production-faithful replica stood up and broken on purpose, and 3 with their source published so the engineering can be read rather than taken on trust. Every figure is a reading, and every write-up includes what did not work first time — usually the part worth reading.
- Measured in production07Every figure was read from a live estate carrying real load.
- Lab-verified02Every figure came from a production-faithful replica stood up for the purpose and broken deliberately.
- Open source01The system is published in full, so the behaviour described can be read in the source rather than taken on trust.
Alarm-to-ticket roll-up
Twenty-one alarms, one ticket, every circuit already on it.
We build the path from your monitor into your ITSM so that one outage opens one incident, with every affected circuit already attached to it.
A fibre span carries many circuits, and cutting it should not produce twenty tickets. We build the alarm-to-incident path — cause-and-symptom grouping in the monitor, CMDB lookup, idempotent ticket creation — and prove it on a replica before it goes anywhere near your live estate.
1 incident opened for 21 rolled-up alarms
- Zabbix 7
- ServiceNow Table API
- Python
- FastAPI
- NOC
- ITSM
HA SNMP trap ingestion
Traps that survive a dead collector, a dead proxy and a cut site link.
We design and prove the trap path for a Zabbix 7 proxy group, so traps keep landing on the right host while the proxies underneath rebalance.
Proxy groups moved hosts between proxies — and quietly broke the usual trap design, because a trap is a datagram that arrives at one place. We build a collector pair that fails over in about a second, fans out to every proxy so rebalancing needs no collector change, and makes no API call anywhere in the trap path.
1.5 s collector failover gap on master kill
- Zabbix 7.4
- SNMP v2c / v3
- Terraform
- Ansible
- Proxmox
- netem
Live database migration and monitoring HA
39.7 million rows moved on a live server. Then the primary was switched off on purpose.
We move your monitoring backend to PostgreSQL and TimescaleDB without stopping collection, then cluster it and stop the primary in front of you to show the collectors follow.
Two pieces of work that belong together: moving a monitoring backend from MariaDB to PostgreSQL 16 with TimescaleDB while the server keeps polling, and clustering it behind a floating address — then stopping the primary, because a failover nobody has performed is a plan rather than a capability.
39.7 M history rows back-filled in 13 min 39 s
- Zabbix 7
- PostgreSQL 16
- TimescaleDB
- MariaDB
- pgloader
- keepalived
Monitoring drift reconciliation
Monitoring cannot catch its own blind spot. This tooling can.
We reconcile your virtualisation inventory against your monitor and hand you the tooling that keeps finding the hosts it thinks it is watching but is not.
A container gets renumbered, the monitor keeps polling the old address, and the alert that lands in your inbox is indistinguishable from a real outage. We reconcile both inventories, report five classes of disagreement, and are careful about the cases the comparison genuinely cannot judge.
5 classes of drift detected
- Python
- Zabbix
- Proxmox
- CI
- Testing
Alert delivery forensics
13 of 10,388 notifications delivered, behind a dashboard that was green.
Before anyone argues about thresholds, we establish whether your alerts can reach a human at all — read from the receiver's logs, not the sender's green tick.
An audit that asks the prior question: can an alert reach a person? One estate had delivered 13 of 10,388 notification attempts in a week, from four independent causes, none of them a threshold. Then the noise: a resend loop producing a thousand emails in six hours, and an uptime monitor showing a service up since April whose binary had never been installed.
13 of 10,388 notification attempts delivered in seven days
- Zabbix
- Uptime Kuma
- SMTP
- Telegram
- Suricata
- Python
Backup integrity audit
A backup you have not restored is a hypothesis.
We attempt a real restore from your real media before the answer matters, then fix the retention, the permissions and the gaps the green job list was hiding.
An audit of a backup estate whose job list was green. It found six guests that had never been backed up — including the single-sign-on host and the monitoring server — sixty-six snapshots never verified, and a retention policy that had silently failed for months on a missing permission.
6 guests never backed up, including SSO and monitoring
- Proxmox Backup Server
- Proxmox VE
- ZFS
- Prometheus
Security assessment and secret hygiene
Sixteen numbered findings, then 28 of 28 checks passing — twice.
We audit read-only, hand you a numbered findings list ordered by risk, fix what you ask us to, and leave behind a harness that re-runs every check and a secret scanner that fails closed.
A read-only audit of an estate that grew organically, the fixes that follow, and the verification harness that proves they held. Then the part that outlasts the engagement: secret scanning that fails closed on the client, on push, and on the server.
16 numbered findings fixed before launch
- OpenSSH
- Gitea
- nftables
- Cloudflare Access
- Proxmox
- Python
Zero-inbound external access
Thirty-five hostnames published without opening a port.
We publish your services to the internet through an outbound tunnel behind single sign-on, with no inbound firewall rule and no exposed origin.
Externally reachable services published through an outbound tunnel, fronted by an OIDC provider and a central directory. No inbound firewall rules, no exposed origin, and single sign-on across the estate — with every hostname tabulated against the access rule that guards it, so a gap is a visible empty cell.
35 public hostnames, 0 inbound firewall rules
- Cloudflare
- Authelia
- OIDC
- OpenLDAP
- nginx
Live topology and telemetry visualisation
A whole estate as one spatial view, legible from across a room.
We build the operations display that answers the first question — what is the estate, and what in it is unhappy right now — and make it degrade legibly when a source dies.
A 3D operations console for virtualised estates. Each hypervisor renders as a spiral galaxy and each guest as a planet, coloured by role and sized by memory, flaring when the monitor raises a problem against it. Built for a wall display, driven entirely by live APIs, and designed so a dead backend removes one layer rather than the scene.
135 nodes in the scene — 80 guests, 48 clients — stable across polls
- Python
- Flask
- Three.js
- WebGL
- Proxmox
- Zabbix
Cortex — multi-agent coding platform
Every AI coding agent, driven from one window.
We build agent tooling that routes each task to a model that can actually do it, isolates parallel agents so their edits cannot collide, and records every run — the reference implementation is published as Cortex.
A self-hosted desktop application for driving multiple AI coding agents — CLI, API and local models — from one window. It routes each task to a model that can actually perform it, runs the work locally, and records what happened so the question of what an agent did has an answer.
3 ways to reach a model — CLI, API, local
- Tauri
- Rust
- React
- TypeScript
- Local LLMs
- MCP
Engagement
How any of this gets bought
Most work starts as an assessment, because it is the cheapest way to find out whether the expensive thing is necessary.
Assessment
A read of what you are running and what is currently untrue about it. Ends in a written findings list ordered by what it costs to fix versus what it costs to leave.
- Inventory of hosts, services and dependencies as they actually are
- Every alert rule reviewed for whether it can fire, whether it should, and whether anyone would receive it
- One restore attempted end to end from real backup media
A written findings list, ranked by risk and effort, that you keep.
Fits when You inherited an estate, or you suspect the dashboards are lying.
Build
Design and delivery of a defined system — a monitoring estate, an alarm-to-ticket integration, an access layer, a backup regime, a hosting platform — including the documentation and the handover.
- Design agreed in writing before anything is provisioned
- Built in version control and rehearsed on a replica, with the configuration reproducible
- Handover session, plus runbooks for the parts that will need touching
A working system you can operate without us.
Fits when You know what you need and want it built once, properly.
Remediation
Targeted work on a system that exists but is not trusted: alert noise, silent gaps, failed restores, an integration that opens duplicate or thin tickets, an access layer nobody can reason about.
- Noise removed first, so the remaining signal can be judged
- Each fix verified against the failure it is supposed to catch
- Changes recorded, so the estate stops being its own only record
A system whose green state means something again.
Fits when It technically works and nobody believes it.
Ongoing
Continuous operation and improvement, with change history, scheduled verification of the things that must not quietly break, and someone to call.
- Scheduled verification of backups, alerting and access paths
- Change history maintained, with a monthly written summary
- A named contact for incidents, with agreed response expectations
The estate stays true after the project ends.
Fits when You need the estate to keep being true after the project ends.