BNC Cloud is the self-hosted platform behind my projects. It gives me a common place for deployments, data services, workflow execution, observability, and agent tooling.
The recorded work begins in May. By the time I prepared this article, the checked-out infrastructure repository contained 68 top-level ArgoCD application definitions. That is a configuration inventory, not a claim that 68 applications are currently healthy.
A platform shaped for a small team
The design is intentionally a small development platform, with production-like deployment discipline and explicit tradeoffs. It is not an assertion of enterprise availability.
The underlying cluster uses k3s on Hetzner, combining cloud workers with a dedicated server connected through a private network. The dedicated machine provides a useful home for memory-heavy workloads. Explicit scheduling constraints keep placement deliberate.
The work involved more than joining a node. The recorded build includes private-network sizing, cloud-controller behaviour, storage differences, and the network path between the two types of machines.
Shared foundations, separate projects
Projects reuse a common set of services: Postgres, a private image registry, secrets management, observability, durable workflows, and agent tools.
That reduces repeated setup, but it creates shared constraints. Database connections are a platform resource. A noisy workload can affect other projects. A network rule is part of the service contract, not a detail each app can ignore.
The platform therefore needs conventions for who owns a resource, how an application gets access, and how a deployment becomes visible.
Git is the desired state
ArgoCD applications connect repository configuration to cluster resources. Built images are pinned, and the configuration records the version intended to run.
This gives a project a repeatable path onto the platform. It also makes configuration drift something that can be inspected instead of remembered.
The inventory includes both third-party software and software I built. Temporal, Radar, ArgoCD, and NetBird are upstream projects that I deploy and configure. The cross-repo skill registry and the BNC console are my own platform components. Those are different kinds of engineering work, and I want the portfolio to describe both accurately.
The less visible work
The most useful lessons often came from operational gaps: connection pools accumulating across applications, a successful health endpoint proving less than expected, or a network test exercising the wrong path.
Those details are why this deserves a series. A list of installed tools shows the ingredients. The decisions and failure modes explain how the platform actually became useful.