A hosting control panel that treats slow as broken. Sites arrive cached, tuned and isolated, and a deployment that measurably slows a site is refused rather than shipped. Two processes: an unprivileged API and a root agent, talking over a typed RPC on a Unix socket. Released binaries carry signed build provenance, because the installer runs as root.
I build self-hosted infrastructure in Go, and I measure what it actually does.
Control planes, backend platforms and deploy tooling. The layer underneath the application, where a wrong assumption costs someone their production server.
Nine years shipping to production, an MSc in Applied Data Science, and a habit of not believing a change works until something has measured it.
Open source
What I'm building
Four projects, all self-hosted, all running code rather than prototypes. Each one ships with its own documentation, security model and CI.
A backend platform in a single binary: collections, auth, realtime and file storage, with PostgreSQL as the only infrastructure. Collections are locked when you create them, and access rules are checked on every read path including file downloads and realtime delivery. A rule enforced on four paths out of five is not enforced.
A Docker Compose control plane that wraps the real docker compose instead of replacing it. The project filesystem stays authoritative, so editing compose.yaml by hand keeps working. Your containers keep running if Windlass stops or is removed, and a lint rule enforces the privilege boundary at build time rather than in review.
Self-hosted appointment scheduling: services, providers, booking pages, calendar conflict checks and email. Authentication is written rather than imported, with revocable session rows, scrypt password hashing in application code, and TOTP to RFC 6238.
Evidence
Measured, on the same box, one at a time
Slipstream benchmarked against CloudPanel on the same physical server, with the OS reinstalled between runs and both panels tuned to their best. The trap in any comparison like this is hardware: two supposedly identical servers of the same spec measured 2.5 times apart for me on the same fixed workload.
| Metric | Slipstream | CloudPanel |
|---|---|---|
| Cached throughput, 500 connections | 9,840 req/s | 2,495 req/s |
| p99 latency at that load | 83 ms | 6.46 s |
| 2,000-connection flood | 8,051 req/s, 0 errors | 163 req/s, 100 timeouts |
| Install, bare server to running panel | 79 s | 410 s |
| Uncacheable WooCommerce render | 189 ms | 168 ms |
The last row is the one Slipstream loses, and it stays on the page. That gap is the measured cost of running every site inside an open_basedir jail: 72 ms of a 301 ms render, found by stracing a worker under load. The jail stays.Full method.
Commercial work
What it did for a business
Leading technical delivery on the rebuild of Sportsafe UK's platform, a national B2B supplier selling to schools, clubs and councils.
50%uplift in organic and campaign traffic
35%increase in conversions
9yrsshipping to production
The order mattered: the GA4 and GTM setup and the technical SEO were rebuilt first, so the reporting was worth trusting before anyone acted on it. Earlier client work includes First Bank PLC and Bluechip Technologies.
Method
How I work
Verify on the wire, not in the file
A directive present in a config is not a directive in effect. I have shipped nginx security headers that were silently dropped by inheritance rules, and a capability probe that read stdout for a tool that writes to stderr. Both looked correct in review and were wrong in production.
Change one variable at a time
Copying someone else's tuning is a hypothesis, not an improvement. Kernel TLS is standard advice and cost 28% of cached throughput on a page-cache workload, so it is not shipped.
Say what did not work
Flattening the release docroot gained about 8% on uncacheable renders and was declined because the risk to the rollback model was not worth it. Both that and the kernel TLS result sit in the code with their numbers attached, so nobody quietly adds them back.