atkrad

Yeah, Argo + Helm double templating is rough. I stayed client-side on purpose so you can still inspect the release with normal helm commands.

Same. Templated YAML is what pushed me away from writing charts by hand.

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.

That is awesome!

Website: https://rivaas.dev Docs: https://rivaas.dev/docs

It's intentional design. They picked a strong visual identity early and applied it consistently; the name, the color palette, the retro terminal feel. Every package looks like it belongs to the same family. Most open source projects never think about this. Charm did from day one.

What is the main difference between this version with the previous one?

Yet another trash!

Thanks for taking the time to look at Rivaas and share your thoughts; much appreciated.