Deployard
A deployment control plane for Kubernetes. The UI talks to a typed API, never to the cluster API server.
Deployard is a deployment control plane for Kubernetes. The web UI and the typed API sit in front of the cluster. Browsers and scripts never hit the API server directly.
Repository: github.com/VladimirKostikov/Deployard.
Built for learning and portfolio work. MIT license.
The problem
Cluster work usually means jumping between tools. kubectl for rollouts and pod status. Docker Compose for local builds. Shell scripts to load images into kind. Separate tabs for logs and port-forwards. Each tool has its own auth and its own failure modes.
Deployard focuses on the deployment lifecycle: what is running, which revision is live, pod health, rollbacks, log tailing, and getting a Compose project into the cluster without a checklist.
What you get
- Deployment list, revision history, scale, restart, rollout undo.
- Live pod status, log tail over SSE, exec console, file browser.
- Parse Compose, preview manifests, build images, load them into kind, apply.
- Services, endpoints, ingress, in-browser access through a controlled port-forward.
- Users, roles, and section permissions: view, operate, manage.
How it is built
pnpm monorepo. React and Vite on the frontend. NestJS with the Kubernetes client on the backend. Shared DTOs in a package. OpenAPI from the controllers.
The frontend never calls Kubernetes. The NestJS process holds kubeconfig, runs JWT sessions with revocation in PostgreSQL, and exposes only whitelisted operations.
Local setup is a small real environment: kind for demo workloads, Docker Compose for Postgres, API, and the nginx UI, Helm chart for a production-style install.
Lens or the Kubernetes Dashboard is enough if you only need a generic explorer. Deployard goes deeper on deployments, operations, and the path from Compose to cluster. Code is in the GitHub repository.
