Representative work

Case studies from production infrastructure

These examples are anonymised and describe the engineering problem, constraints, and operating result without disclosing employer or customer-sensitive implementation details.

Virtualisation and migration

Modernising a large OpenVZ 7 hosting estate toward Proxmox LXC

Situation

A mature hosting platform operated hundreds of physical nodes and a large population of customer containers. Its OpenVZ 7 and legacy control-plane assumptions had become a long-term operational constraint.

Constraints

  • • Existing customer environments could not simply be rebuilt as clean greenfield systems.
  • • Storage layout, container privilege, application compatibility, networking, monitoring, and commercial provisioning all had to remain coherent.
  • • Migration needed staged validation and an operational fallback—not a single irreversible cut-over.

Engineering work

  • • Defined Proxmox LXC node and container standards, including privileged and unprivileged workload classes.
  • • Designed repeatable template/build processes and integration points for existing provisioning workflows.
  • • Investigated compatibility details across systemd, capabilities, AppArmor, Docker nesting, TUN/FUSE devices, storage, and user applications.
  • • Built operational tooling and documentation to reduce differences between the legacy and target platforms.

Operational result

The migration became an engineering programme with explicit standards, testable workload classes, and repeatable build mechanics rather than an improvised per-customer conversion.

OpenVZ 7 · Proxmox VE · LXC · Linux capabilities · AppArmor · Ansible · Bash · systemd · LVM-thin

Monitoring and capacity

Turning a distributed hosting fleet into an observable operating system

Situation

A multi-tenant VPS and seedbox platform required visibility across physical nodes, customer containers, storage, applications, and commercial usage—not merely isolated host dashboards.

Constraints

  • • Thousands of workloads created high metric cardinality and made instance-by-instance dashboards insufficient.
  • • Operational questions crossed infrastructure and customer metadata boundaries.
  • • The system needed long-term retention, practical alerting, and dashboards that surfaced abnormal nodes rather than requiring manual browsing.

Engineering work

  • • Developed and operated Prometheus and Thanos monitoring for distributed infrastructure.
  • • Created custom exporters and SQL-backed mappings to connect system metrics with customer and plan context.
  • • Built PromQL and Grafana views for fleet health, utilisation, abnormal behaviour, capacity, and service-specific events.
  • • Improved alerting and telemetry around storage, network, application usage, and platform behaviour.

Operational result

Operations gained a shared measurement layer for investigating failures, comparing node behaviour, planning capacity, and validating platform changes across the fleet.

Prometheus · Thanos · Grafana · Alertmanager · node_exporter · SQL · PromQL · Python · Bash

Automation and customer platforms

Standardising application delivery across multi-tenant Linux containers

Situation

Customers expected one-click installation and reliable lifecycle management for a varied catalogue of seedbox and media applications running inside individually managed Linux environments.

Constraints

  • • Applications used a mixture of packages, source builds, repositories, containers, reverse proxies, and per-user services.
  • • Upstream releases and OS upgrades could overwrite local changes or invalidate assumptions.
  • • Installers had to be repeatable, supportable, and compatible with platform provisioning and customer permissions.

Engineering work

  • • Created and maintained installers, packages, templates, service definitions, reverse-proxy integration, and upgrade logic.
  • • Used Ansible to deploy common components and regenerate per-user configuration across nodes.
  • • Investigated application-specific behaviour in Deluge, qBittorrent, ruTorrent/rTorrent, media services, Docker, nginx, and systemd.
  • • Introduced safer wrappers and privilege boundaries where web-facing tools needed controlled system operations.

Operational result

Application delivery shifted from individual manual installation toward a consistent platform capability with repeatable deployment, controlled privileges, and maintainable operational patterns.

Ansible · Bash · Python · Debian packaging · systemd · nginx · Docker · LXC · torrent and media applications

Your system will have different constraints

The point of these examples is not to sell a fixed recipe. It is to show the type and depth of production problem I can take ownership of.

Discuss a similar problem