How Partiri Is Built: Kubernetes, Rust and Go
Published 4 August 2026
Built on Kubernetes, from scratch
Partiri isn't a thin dashboard bolted onto a single vendor's managed platform. Every layer between "click deploy" and a running pod — the job queue, the build pipeline, the chart that finally creates your Deployment or CronJob — is code written specifically for Kubernetes. That trade-off costs more engineering time up front than reselling someone else's control plane, but it means the platform isn't limited to whatever a third party decided to expose.
What actually happens when you deploy
- You create or update a service from the Harbor web dashboard; the configuration is saved to PostgreSQL through the Harbor API.
- The Harbor API validates the request and enqueues a deployment job.
- A Go daemon called Carpenter polls for open jobs, renders a Helm values file for your service, and calls the Helm SDK directly — no shelling out to a `helm` binary.
- Navigator's Helm charts and Kubernetes manifests configure the Deployment or Job, ingress routing, and TLS.
- For Git-based deploys, a small Rust tool called Swabber clones your repository and strips anything that shouldn't ship in a build context — secrets, private keys, binaries, symlinks — before the build runs. Registry-image deploys skip this step entirely, since there's no repository to sanitize.
- Once the workload is running, another Rust service, Storyteller, watches your pods, Jobs and CronJobs across the cluster and reports status back to the API — which is what powers the live status you see on a service's detail page.
The services behind the platform
| Service | Language | Role |
|---|---|---|
| Harbor API | TypeScript (NestJS) | Public REST API — workspaces, services, billing, auth |
| Harbor Web | TypeScript (Angular, SSR) | The dashboard and this marketing site |
| Carpenter | Go | Polls deployment and volume jobs, drives Helm and Kubernetes directly via their Go SDKs |
| Storyteller | Rust (tokio) | Watches pod, Job and CronJob status across clusters |
| Swabber | Rust | Sanitizes cloned repositories for secrets and unsafe files before a build |
| Navigator | Helm / Kubernetes YAML | Charts and automation that define how a workload actually runs |
Carpenter itself has an interesting history: it started life as a Rust service and was later rewritten in Go to invoke the Helm SDK in-process rather than shelling out. That kind of internal churn is normal for a platform built in-house — the point isn't that any one service stays in one language forever, it's that we own the whole chain and can make that call.
Security by default, not opt-in
Every customer workload the runtime chart deploys runs as a non-root user (UID 1001), with a read-only root filesystem, all Linux capabilities dropped, no privilege escalation, and the default seccomp profile enforced. Network policies isolate tenants from each other at the cluster level. None of this is a paid add-on or something you have to turn on — it's the only mode the runtime chart supports.
Runtimes you can deploy today
Beyond deploying your own Docker or registry images directly, Partiri builds and runs applications in Node.js, Python, Go, Rust, PHP, Ruby, JVM (Java and Kotlin), .NET, C++, and Elixir, plus a Caddy-based image for static sites. Each runtime is built for both x86_64 and arm64.
Why we built it this way
Owning the full stack — from the job scheduler to the Kubernetes chart — is what lets Partiri run entirely on infrastructure physically located in the EU, without depending on a hyperscaler's regional footprint or control plane. It also means scheduling, storage, and observability can evolve independently, on our own timeline, instead of waiting on a platform vendor's roadmap.