KuberTech.dev is the development view of the same KuberTech network: the place Kubernetes, automation and GitOps changes are worked through before production is updated.
It keeps experimentation useful rather than reckless: realistic services, familiar boundaries, controlled blast radius and a record of what was promoted, tightened or rejected.
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.dev shows the development side of the environment: what is being tested, how promotion works, which guardrails stay in place and what has recently changed.
The same codebase now supports two clear roles: kubertech.io is production, while kubertech.dev is the development environment used to work through change.
Both site variants are built and validated together so the production and development narratives cannot drift silently.
Selected workloads use Image Updater boundaries that can be observed in development before production automation is allowed to change behaviour.
k3s upgrade and maintenance automation is kept visible so sequencing, recovery and operator impact can be checked before production is touched.
Routing, TLS material and Cloudflare edge connectivity are validated together because they operate, and fail, as a system rather than isolated manifests.
Describe the change in a base application, development overlay, AppProject boundary or automation policy before it becomes cluster state.
Let Argo CD apply the development state and check the result against real platform services, not a throwaway example environment.
Review routing, secrets, storage, runner behaviour and maintenance impact before calling the change safe enough to promote.
Move the equivalent change into production only after the development environment has proved the path and exposed the operational consequences.
Keep a short note of what changed, what was learned and whether the pattern should be reused, tightened or avoided.
Development uses the same AppProjects, namespace boundaries and explicit repository sources as production, so testing happens inside realistic constraints.
Secrets remain externalised and are never exposed through the public site, generated output or repository content.
Development can expose failed approaches, but drift, hidden changes and unclear rollback paths are not allowed to become normal operating behaviour.
2026-06-08
promoted
KuberTech.io now presents the production network view while KuberTech.dev explains the development environment, guardrails and promotion flow.
2026-06-08
promoted
The build and validation path checks both production and development variants so the paired-domain model stays intentional.
2026-06-08
watching
Internal-facing workloads are described by purpose and access expectation so the site reads as controlled operation, not accidental exposure.
kubertech.dev 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 development 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.