Fair points. A few clarifications though. On cluster access: Deployah does not ask you to hand developers cluster-admin on prod. It is a client-side CLI, same

Fair points. A few clarifications though. 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.