KuberTech.io is the production view of my KuberTech network: a Kubernetes and GitOps platform used to run useful services and show how I design, automate and operate infrastructure.
The wider network traces back to 1997, when small private LANs were the practical answer to a UK internet landscape still dominated by dial-up access, cost and limited bandwidth. It has grown into an ISP-style development platform on virtualised and co-located infrastructure, where I research new technology and keep automation, recovery, networking and platform judgement practical.
Simon Oakes has been building and running networks since 1997, starting with small private LANs at a time when UK internet access was still mostly dial-up, expensive and bandwidth-limited. Today the wider environment spans virtualised and co-located systems across datacentres, runs useful services and gives new tools a realistic place to prove themselves. This site turns that operating model into something public, reviewable and safe to share.
soakes@uk
KuberTech is the public slice of the development network Simon Oakes uses today to operate useful services, research new technology and keep Linux, Kubernetes, networking, automation and recovery skills grounded in practical infrastructure.
k3s workloads, namespaces, AppProjects and cluster boundaries that are visible enough to review.
Argo CD reconciliation, automated prune, self-heal and environment overlays for controlled change.
Ingress, secrets, storage, runners, maintenance and recovery treated as one operating system.
Repeatable build, validation, release and deployment paths rather than manual cluster ceremony.
Pages, DNS, edge routing and safe public metadata handled as part of the delivery model.
GitHub Actions validation, paired builds, release artifacts and self-hosted runner boundaries.
Snapshots, unseal paths, controlled reboots and upgrade sequencing kept visible before incidents.
Real operational signals without publishing credentials, private endpoints or sensitive topology.
Go / GoBGP / Linux
Go-based RTBH daemon that turns threat feeds into controlled BGP blackhole announcements for production-grade network defence automation.
repository ->Python / S3 / DR
Production-minded S3 mirroring utility with parallel transfer, structured logging and disaster-recovery workflows.
repository ->Go / S3 / IAM
Operator CLI for bucket provisioning, scoped IAM credentials and batch operations across S3-compatible storage.
repository ->It is a controlled slice of a larger environment used for real services, research and long-running practice across Kubernetes, Linux, networking, automation and recovery.
1997 to now
That path started with small private LANs in the dial-up era, when reliable local networking was the practical way to connect systems and move data. It grew into a datacentre-hosted development platform, keeping learning tied to real systems instead of throwaway examples.
real services
Services are operated with the same habits expected at work: clear ownership, controlled exposure, repeatable change, maintenance windows and recovery paths.
reviewed desired state
Argo CD reconciles reviewed application state from Git, with automated prune and self-heal policies used to keep drift visible and correctable.
ISP roots
DNS, routing, VPNs, mail, ingress, certificates and edge connectivity are treated as part of the platform, not as detached service plumbing.
less manual drift
Ingress, certificates, secret sync, storage, runners, maintenance and upgrades are handled as repeatable platform capabilities rather than manual cluster chores.
designed to fix
Vault snapshots, unseal automation, controlled reboots and k3s upgrade plans keep failure handling and maintenance visible before pressure arrives.
KuberTech.io shows the production side of the environment: the bounded application set, the GitOps model and the platform practices used for the public view of the network.
kubertech.io
KuberTech.io shows the production side of KuberTech that is safe to describe publicly: what runs, how it is bounded and how change is handled.
proved first
Platform and workload changes are exercised on the development side before the production view is updated, keeping experiments away from the public operating posture.
clear blast radius
Applications are grouped by namespace, AppProject, repository source and platform responsibility so the blast radius is visible before work reaches the cluster.
designed for recovery
Maintenance, unseal, backup and upgrade work is treated as part of the platform story, not as hidden manual effort that only appears during an incident.
kubertech.io groups Kubernetes applications by the role they play in the platform: workloads, ingress, certificates, secrets, storage, CI/CD runners and maintenance automation. The useful signal is not the manifest count; it is whether the operating model is easy to reason about and safe to change.
namespace/squid
Caching forward proxy used for controlled network egress and development traffic patterns.
namespace/vaultwarden
Self-hosted password vault workload operated with private access, clear routing expectations and backup consideration.
namespace/vlmcsd
Internal licence activation workload for authorised development systems inside the wider network.
namespace/phpipam
IP address management workload for network records and address planning across the development network.
namespace/speedtest-tracker
Internet performance monitoring workload used to track network behaviour over time.
namespace/termbin
Terminal-friendly paste service for controlled operator handoff and short-lived diagnostic notes.
namespace/transfer
Command-line file handoff service used inside the wider network with controlled access expectations.
namespace/ninerouter
Routed AI access service with image guard automation and controlled promotion expectations.
namespace/cloudflare
Cloudflare edge connectivity for controlled ingress into the KuberTech network.
namespace/metallb-system
Installs MetalLB custom resources ahead of the controller so load-balancer state has a reliable API surface.
namespace/metallb-system
Provides load-balancer IP allocation for services inside the Kubernetes network.
namespace/kube-system
Ingress routing layer for HTTP and TCP services, separated from TLS material and edge policy.
namespace/external-secrets
Synchronises external secret material into Kubernetes namespaces without publishing sensitive values in Git.
namespace/reflector
Reflects selected secrets and config maps into target namespaces where shared platform material is required.
namespace/cert-manager
Automates certificate resources and lifecycle management for services inside the cluster.
namespace/external-secrets
Creates the TLS secret material consumed by Traefik routes without coupling certificates directly to ingress configuration.
Self-hosted GitHub Actions runners for trusted automation jobs close to the platform.
GitLab runner fleet for pipeline work that benefits from being close to the Kubernetes platform.
Dynamic NFS-backed persistent volume provisioning for workloads that need shared storage.
namespace/kube-system
Coordinates node reboots inside a defined maintenance window so patching remains predictable.
namespace/vault-unseal
Automates Vault unseal operations so the platform secret backend has a recoverable operating path.
namespace/vault-raft-snapshot-agent
Captures Vault raft snapshots so backup and recovery posture is part of normal operations.
namespace/system-upgrade
System Upgrade Controller for automated k3s upgrade plans and repeatable node maintenance.
Provides Kubernetes resource metrics used for scheduling, checks and day-to-day platform visibility.
The production plane is represented through Argo CD Applications, AppProjects, Image Updater policies and storage resources so repository access, namespaces and automation scope are clear before anything reaches the cluster.
external-secrets
namespace/external-secrets
traefik
namespace/kube-system
github-actions-runners
namespace/github-actions-runners
system-upgrade
namespace/system-upgrade
nfs-subdir-external-provisioner
namespace/kube-system
Ingress, certificates, secrets, load balancing, storage, maintenance and build runners are separated into service groups so each capability has a clear purpose, boundary and recovery expectation.
networking
Traefik handles cluster routing, TLS material is reconciled separately, and Cloudflare provides the controlled external edge path.
secrets
Certificate resources, external secret sync and namespace reflection are managed as first-class platform services rather than ad-hoc workload details.
networking
MetalLB CRDs and controller state are split so the controller reconciles only after its API surface is present.
storage
NFS-backed dynamic provisioning supplies persistent volumes for workloads that need shared storage without hand-built volume steps.
maintenance
Reboots, k3s upgrade plans, Vault unseal and Vault raft snapshots are managed through GitOps-controlled applications so recovery work is visible.
automation
Self-hosted GitHub and GitLab runners keep automation close to the platform while remaining declared, bounded and GitOps-managed.
Base applications, environment overlays, AppProjects and automation policies are split deliberately so changes can be reviewed, constrained, reconciled and promoted without relying on memory or manual cluster work.
Promotion model
Development and production sides use the same application model, giving platform and workload changes a repeatable path from testing to release.
Sync policy
Automated reconciliation keeps the cluster aligned to reviewed Git state, including pruning obsolete resources and self-healing configuration drift.
Applications and AppProjects are versioned in apps-appify-k8s under shared base and environment overlay paths.
AppProjects limit each app to explicit source repositories, namespaces and cluster permissions before reconciliation starts.
Argo CD applies desired state with automated prune and self-heal enabled across the app set.
The development overlay proves platform and workload changes before the same operating model moves to production.
base/appsShared Argo CD Applications used by both production and development environments so common platform behaviour is defined once.
overlays/prod/appsProduction application resources and patches for the public network view.
overlays/dev/appsDevelopment application resources and patches for testing before production promotion.
overlays/*/projectsAppProject boundaries for allowed repositories, namespaces and cluster resources.
overlays/*/argocdArgo CD Image Updater write-back policies for selected workloads where image automation is intentionally bounded.
overlays/*/storageStorage provider Applications kept separate from normal workload apps so persistence concerns are easy to review.