Building the platform behind my projects.

My independent projects need somewhere to run, and I am responsible for what happens after deployment. That has led me to build and operate a self-hosted environment connecting applications, databases, workflows, AI services and observability.

Purple Hive is one application within that wider platform. The infrastructure story spans Hive, APEX, Purple Guard and the shared services they depend on. Its value to me is the experience of keeping those dependencies understandable, deployable and recoverable.

My contribution

I operate this environment and work across deployment, networking, container runtimes, storage, monitoring and recovery. AI tools assist with implementation and investigation; I remain responsible for reviewing changes and deciding what is safe to execute.

This is independent infrastructure, separate from my work at Corti. It gives me room to test ideas and learn from their consequences without presenting a personal single-server environment as a large production platform.

The platform I operate

The documented architecture combines Docker-hosted stateful services with k3s application workloads. PostgreSQL and n8n support data and automation; applications including Hive, Guard and APEX depend on those shared services.

Caddy provides reverse-proxy routing. The operational toolchain includes Prometheus for metrics, Loki for logs and Grafana for investigation and alerting. Bash deployment scripts, Kubernetes manifests and runbooks connect the intended architecture to repeatable operating steps.

The interesting work is at the boundaries. A healthy process does not prove that its database is reachable. An image visible to Docker is not necessarily available to the Kubernetes runtime. A proxy route can work while a downstream dependency fails.

Why the deployment model matters

Application images are built locally and imported into k3s containerd rather than retrieved from a conventional registry. That makes the local image store part of both deployment and recovery.

The release process uses immutable image tags, verifies image availability before replacing a workload, checks health afterwards and retains an explicit rollback path. These controls were developed over time; they did not all originate in one incident.

There are tradeoffs. A single host remains a shared failure boundary. Some documented deployment paths use replacement rather than overlapping replicas. Kubernetes does not turn those constraints into high availability by itself.

Working with those limits has taught me to distinguish a deployment mechanism from a reliability guarantee.

The decision

I want to be able to explain how a release reaches the runtime, what it depends on, which signals indicate failure and how to return to a known state.

That means maintaining more than application code. It includes image retention, storage capacity, health verification, dependency-aware recovery and documentation another operator can use. A successful deployment should leave evidence of what changed, not just a terminal that stopped printing errors.

An incident that tested the model

Disk pressure triggered Kubernetes eviction behaviour and locally held application images were garbage-collected. During recovery, modifying containerd state while the runtime was active damaged the snapshotter and prevented workloads from starting correctly.

I worked through storage, runtime state, local images, manifests and dependent services to recover the environment. Afterwards, I questioned the explanation for the original capacity problem.

The assumption was that the k3s image store dominated root disk use. Measurement showed it was approximately 9 GB, while another container content store was approximately 17 GB. Superseded APEX build tags were a more valuable cleanup target than the migration being prepared.

The runbook records root filesystem utilisation falling from roughly 85% to 52% after targeted cleanup on 1 September 2026, without taking the platform down. Those are historical measurements, not live capacity figures.

The lesson was specific: identify the largest safe consumer, preserve the current release and rollback images, and only pursue a disruptive migration if the remaining measurements justify it.

What I learned about operating systems

Recovery requires a model of dependencies. Restarting one component cannot repair every failure underneath it, and an apparently successful command may leave the system unusable.

Observability has to follow those dependencies too. Host capacity, container health, database behaviour, application metrics and logs answer different questions. I use them together to narrow a failure rather than treating a green dashboard as a complete explanation.

Documentation is part of the recovery design. The runbook records mistaken assumptions and unsafe approaches as well as the eventual fix. That makes the learning reusable when I am not the person investigating.

The next level of challenge

I want to keep improving the environment’s recovery and capacity model before increasing its complexity. The next questions are how convincingly I can prove restoration, how early I can detect a dependency failure and how clearly someone else can operate a release.

As requirements grow, I want to evaluate which services need stronger isolation, which need a different image distribution model and when additional nodes would deliver a measurable benefit. Those are future architecture decisions to test against real demand, not capabilities I claim to have already delivered.

What I would bring to a team

This work shows how I approach infrastructure: understand the dependency chain, make the change reversible where possible, verify the outcome and leave a usable operating record.

Alongside my professional experience across identity, endpoints and engineering infrastructure, it gives me practical grounding for platform and reliability work. I enjoy moving between those layers—and I want to deepen that experience in a team operating at a larger scale.