Deployard
Eine Control Plane für Kubernetes-Deployments. Die UI spricht mit einer typisierten API, nie mit dem Cluster-API-Server.
Deployard ist eine Control Plane für Kubernetes-Deployments. Web-UI und typisierte API sitzen vor dem Cluster. Browser und Skripte treffen den API-Server nicht direkt.
Repository: github.com/VladimirKostikov/Deployard.
Gebaut für Lernen und Portfolio. MIT-Lizenz.
Das Problem
Clusterarbeit heißt meist Springen zwischen Tools. kubectl für Rollouts und Pod-Status. Docker Compose für lokale Builds. Shell-Skripte, um Images in kind zu laden. Extra-Tabs für Logs und Port-Forwards. Jedes Tool hat eigene Auth und eigene Fehlerbilder.
Deployard hält den Deployment-Lebenszyklus: was läuft, welche Revision live ist, Pod-Gesundheit, Rollbacks, Log-Tail und der Weg eines Compose-Projekts in den Cluster ohne Checkliste.
Was du bekommst
- Deployment-Liste, Revisionshistorie, Scale, Restart, Rollout-Undo.
- Live-Pod-Status, Log-Tail über SSE, Exec-Konsole, Dateibrowser.
- Compose parsen, Manifeste previewen, Images bauen, in kind laden, apply.
- Services, Endpoints, Ingress, Browser-Zugriff über kontrolliertes Port-Forward.
- User, Rollen und Rechte pro Abschnitt: view, operate, manage.
Wie es gebaut ist
pnpm-Monorepo. React und Vite im Frontend. NestJS mit Kubernetes-Client im Backend. Geteilte DTOs in einem Paket. OpenAPI aus den Controllern.
Das Frontend ruft Kubernetes nicht. Der NestJS-Prozess hält kubeconfig, JWT-Sessions mit Widerruf in PostgreSQL und gibt nur eine Whitelist von Operationen frei.
Das lokale Setup ist eine kleine echte Umgebung: kind für Demo-Workloads, Docker Compose für Postgres, API und nginx-UI, Helm-Chart für eine produktionsnahe Installation.
Lens oder das Kubernetes Dashboard reicht, wenn du nur einen generischen Explorer brauchst. Deployard geht tiefer bei Deployments, Betrieb und dem Weg von Compose in den Cluster. Code im GitHub-Repository.