Deployah
<p align="center" <img src="https://deployah.dev/demos/nginx.gif" alt="Deployah: write a short nginx spec, deploy to a local cluster, get a URL" width="800" </p <!-- markdownlint-enable MD033 --
Deployah is a CLI that deploys apps to Kubernetes. You write a short spec. Deployah turns it into a running Helm release. That flow is Spec-to-Release: like Source-to-Image (S2I), but for the deploy step. S2I builds your image. Deployah runs your release.
The binary embeds the Helm and Kubernetes clients. It installs nothing in your cluster. You do not maintain a chart.
Who this is for
Deployah is for teams that already use Kubernetes and want a clear ownership boundary between the app and the platform.
- App / developer owns deployah.yaml: image, port, resources, expose
intent, scaling, persistence, workers. No Kubernetes context. No real domain names.
- Platform owns deployah.platform.yaml: cluster contexts, domains, TLS,
and profiles (placement, security, monitor labels, and related policy).
You still need a cluster you can reach (kubeconfig). Deployah talks to that cluster itself.
Use Deployah when
- You want multi-environment app deploys without maintaining a chart per app
- Platform policy (domains, TLS, profiles) should change without editing every
app spec
- The common shapes are enough: Deployment/StatefulSet, Service, Ingress, HPA,
PVC, workers, ServiceMonitor/PodMonitor
Do not use Deployah when
- You already have a Helm chart and release process you trust for that app
- You only need a one-shot (kubectl create deployment or helm install of a