KNS Consultancy · AI automation & DevOps

Automation that runs when nobody is watching.

I build AI automation for the systems a business actually runs on — ERP, production databases, and the Kubernetes clusters underneath them. Ten years keeping infrastructure alive for businesses that cannot afford downtime.

Start a conversation See what I run

Harare · UTC+2 — overlapping London, the EU and most of a US morning

Services

Five services, monitored the way everything else is.

These are the things I am called for. Each one is a real engagement shape, not a capability list — and three of them are easier to show than to describe.

AI Automation

n8n and Make workflows that reach real systems

Platform & Kubernetes

Clusters, OpenShift, multi-cluster management

ERP Integration

Rollouts, upgrades and integrations across client estates

Data & Backups

PostgreSQL at scale, replication, tested restores

Security & Secrets

Hardening, TLS, Vault, least-privilege access

argo cd · fleet reconciliation

A commit reaches every cluster, and each one reconciles itself to match. What runs is what is committed — drift shows up in minutes, not during an incident.

ansible-playbook · base-hardening.yml

PLAY [base-hardening] ****************************TASK [ssh :: key-only auth] okTASK [firewall :: default deny] changedTASK [mariadb :: buffer pool] okPLAY RECAP  ok=42  changed=7  failed=0

The same playbook builds every environment the same way. Differences between clients are variables, not somebody’s memory — which is why failed=0 is the expected result rather than a good day.

vault · dynamic credential

Nothing holds a permanent database password. An application asks, the policy is checked, and the credential it gets has a clock on it — so a secret that leaks has already expired.

Stack

n8n
Make
Kubernetes
OpenShift
K3s / Rancher
Ansible
Terraform
GitLab CI/CD
Argo CD
PostgreSQL
Docker / Podman
HashiCorp Vault
Python
Authelia
Graylog

The readout

20+

Kubernetes / OpenShift clusters

200+

nodes under management

15+

companies served

2,800+

users depending on it

2TB+

production PostgreSQL

10+

enterprise ERP environments

automations running unattended

Incidents

Four systems, and what was actually wrong with them.

Written as incident reports, because that is how the work is recorded when it happens. Clients are described by sector, never named.

INC-001RESOLVED

Self-hosted AI automation platform

A multi-company FMCG group

n8n on Kubernetes behind 2FA · 8 automations unattended

01Mapped what was actually being done by hand, and what it cost
02Built the platform, hardened it, put credentials behind Vault
03Moved automations across one at a time, watching each for a full cycle

Problem: Work that mattered was being done by hand, on a schedule that depended on somebody remembering. The data lived in an enterprise ERP, production databases and a set of internal APIs that had never been designed to talk to each other.
Build: A self-hosted n8n platform on Kubernetes, behind Authelia for 2FA, with credentials held in Vault rather than in workflow definitions. Each automation reaches the ERP, the databases and the internal APIs directly, with its own least-privilege access.
Outcome: Eight automations now run unattended in production. Nothing waits on somebody remembering, and every run leaves a trace you can read afterwards.

INC-002RESOLVED

Multi-cluster platform with GitOps

An enterprise platform estate spanning multiple business units

20+ clusters · 200+ nodes · Red Hat ACM/ACS · GitLab CI/CD

01Inventoried the fleet and found where it had drifted
02Put cluster configuration into Git, with review on the way in
03Handed reconciliation to Argo CD and stopped applying by hand

Problem: Twenty-plus clusters and two hundred-plus nodes had drifted apart. Nobody could say with confidence what was running where, because what was running was whatever had last been applied by hand.
Build: Red Hat Advanced Cluster Management and Advanced Cluster Security over the fleet, with GitLab CI/CD and Argo CD driving every change. Cluster state became a pull request, and reconciliation became continuous.
Outcome: What runs is what is committed. Drift is visible within minutes instead of surfacing during an incident, and a new cluster joins the fleet already configured.

INC-003RESOLVED

Automated ERP deployment

Ten-plus enterprise ERP client environments

10+ client environments · provisioning to upgrade · no manual steps

01Wrote down what the build actually was, step by step
02Turned each step into a task, and each client difference into a variable
03Ran it against every environment until the playbooks were the only path in

Problem: Every ERP environment was built by hand, so every environment was subtly different. Upgrades were slow because nobody was certain what they were upgrading, and a difference only showed up once it had broken something.
Build: Ansible playbooks covering the whole path — provisioning, configuration, deployment and upgrade — run the same way against every client environment, with the differences between clients expressed as variables rather than as memory.
Outcome: Ten-plus environments are now built and upgraded from the same playbooks with no manual steps. A new environment is a run, not a project.

INC-004RESOLVED

Hardened logging pipeline

A gaming technology company

Graylog · Elasticsearch authentication · TLS end to end

01Traced every hop a log line took and found where it travelled in the clear
02Put authentication in front of Elasticsearch
03Terminated TLS at every hop, then verified it from outside

Problem: The logging pipeline was the one system that saw everything, and it was the one system nobody had hardened. Elasticsearch sat open behind the pipeline, and traffic between components was in the clear.
Build: Authentication put in front of Elasticsearch, TLS terminated properly at every hop rather than only at the edge, and Graylog configured so that a compromised component could not read the whole estate.
Outcome: Logs are encrypted in transit end to end and readable only by the things that should read them. The system that sees everything is no longer the softest way in.

Standards

The standard my servers are built to.

How I build a LAMP VPS for production — the actual document, not a summary of one. Hardening, TLS, backups, and the order things happen in. Take it whether you hire me or not.

Download the build standardPDF · 45 KB

Uptime history

Ten years, one bar per quarter.

A status page shows ninety days. This is the same chart over a career — every quarter green, with the quarters that added a certification marked.

2016 — 2025 · 40 quartersNo outages

Hover a quarter

Ten years. Twelve certifications. Still green.

Twelve certifications, all live

Verify all twelve · rhtapps.redhat.com — cert ID 160-147-195

RHCA — Red Hat Certified ArchitectRed Hat · 2024
RHCE in Red Hat OpenShift (EX380)Red Hat · 2023
RHCSA in Red Hat OpenShift (EX280)Red Hat · 2023
MultiCluster Management (EX480)Red Hat · 2024
Cloud-native Applications: EngineerRed Hat · 2023
Cloud-native Applications: DeveloperRed Hat · 2023
Cloud-native Applications: Advanced DeveloperRed Hat · 2023
Advanced System Administrator in OpenShiftRed Hat · 2023
RHCE in Enterprise LinuxRed Hat · 2016
RHCSA in Enterprise LinuxRed Hat · 2016
CKA — Certified Kubernetes AdministratorCNCF · 2021
CKAD — Certified Kubernetes Application DeveloperCNCF · 2022

Also heldHashiCorp Vault Associate · Terraform Associate · PCEP · Azure Fundamentals · GitOps Fundamentals · AWS Solutions Architect – Associate

Contact

Tell me what you’re trying to connect.

The useful first message is one line about the systems involved and what should happen between them. If it is not worth building, I will say so.

Response time: Within one working day, on UTC+2.
Direct: trust@knsprojects.online
Based: Harare, Zimbabwe · consulting into South Africa, the UK and the US.