For starters, having nothing running in the clusters means you have to give rw cluster access to developers. Developers should not be allowed near production without adult supervision.
Then, it simplifies nothing but adds its own complexity on top. You still need to understand helm for when this tool will (inevitably!) produce something that doesn't work the way you thought it would or when it produces something that doesn't match the mental model you made about it.
Also it seems to also spin local kubernetes clusters?
Also it seems to be have a dependency on nip.io hard-coded? Looks like an easy jackpot kind of target ? (you hijack nip.io dns records, you get a bunch of traffic from developers' laptop).
So a bad idea overall in my opinion.
On cluster access: Deployah does not ask you to hand developers cluster-admin on prod. It is a client-side CLI, same class as helm/kubectl. Whoever runs it needs whatever RBAC you already give that identity. The intended split is deployah.yaml for the app, and deployah.platform.yaml for contexts, domains, TLS, profiles. Platform/ops can own that second file, and prod deploys can stay in CI with a locked-down service account. If your bar is "no human kube credentials on prod at all", this is not the tool, and neither is bare helm from a laptop.
On Helm: agree that when something breaks, being able to run helm get / helm history helps. The goal is not "never learn Kubernetes". It is "do not write a chart for every small app". Day to day you work with the spec; the release is still a normal Helm release if you need to inspect it.
On local clusters: yes, optional. deployah cluster up is for laptop/dev only. Prod is just a kubeconfig context from the platform file.
On nip.io: that is only the scaffold default for the local environment (127.0.0.1.nip.io), so you get a hostname without editing /etc/hosts. Production domains come from deployah.platform.yaml, e.g. example.com with cert-manager. If you do not want nip.io even locally, change baseDomain. The "hijack nip.io, steal laptop traffic" risk is real for any tool that defaults to nip.io for local URLs; it is not hard-coded into prod deploys.
So I would not point this at unmanaged prod clusters either. The fit I care about is local/dev and small teams that already have a kubeconfig and do not want an in-cluster PaaS. Happy to hear where that still looks wrong.
gopherly•58m ago
I mean the middle ground: not hand-writing charts/YAML, and not installing an in-cluster PaaS either. What do people actually use for that, especially CLI-only?
verdverm•52m ago
This post is also using helm, putting a DSL in front because yaml sucks and templated yaml is insane. The problem here is the DSL, devs don't want a DSL for k8s ime, it becomes yet another abstraction of complexity. I render full k8s yaml for helm and avoid the templates
mring33621•47m ago
I'm happy to hear that I'm not the only one that thinks this.
verdverm•39m ago
atkrad•13m ago
atkrad•17m ago