This is a good bridge to something new eventually. There is Timoni, which was a CUE based attempt to replace Helm, but imo, it stayed too true to helm concepts and missed the opportunities CUE enables.
From experience, you will likely get the most pushback / dropoff from the DSL. Like people want to get at helm if needed, creating an abstraction (DSL) of the underlying k8s constructs will make it too challenging to get at the actual underlying k8s resources. I get that yaml is repeatative and there is a place for reuse, but a custom CLI and DSL is not paletable.
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.
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.
This has led to a completely overblown design of at least their website. All these cutesy pictures of bubble tea, way too big graphical wrappers, no simple page that is labeled "screenshots", no explanation what "bubbletea" actually is, ... One would think it to be a simple task to mention somewhere that this is a TUI library, where one can see it at the first glance. But apparently not. Instead I am seeing:
Your new coding bestie, now available in your favourite terminal. Your tools, your code, and your workflows, wired into your LLM of choice. This is artificial intelligence made glamourous.
Eh, so something about AI tools? And is "Crush" another tool than "bubbletea"? Why am I seeing something about "Crush" and not about "bubbletea"?
Maybe it's simply not my taste. For a TUI library, I expect serious listings of what it can do, what it supports, what it helps you with. Is it a layer on top of ncurses? Features and use-cases over meaningless authority arguments like "Look who uses this too!".
I also see:
We make the command line glamorous.
I don't want my command line to change! I configured it to be just how I like it. What they mean is, that they make command line applications using their library "glamorous" (whatever that means). I have a suggestion for a better slogan: "Your advanced command line widgets library" or "Library for advanced TUI applications".
I think it's both completely valid to feel this way, and also valid for them to have fun with their design and aesthetic. If you already know what charm does, it makes perfect sense and is cool to see.
In a world of boring corporate "rounded corners are less aggressive" websites and app designs, I really appreciate something that is more out there. Crush is their "opencode"-ish app and is my go to when not using CC or CopilotCLI directly. Sure, it everyone's cup of (bubble) tea but that is kind of the great part, it doesn't have to nor does try to be.
From my interactions with younger engineers, this is what "they're looking for". I think we're just used to a different format, so our expectations don't match the reality. Our instincts are different, maybe? Not sure.
Ok but who cares about your finance department, and more importantly, why would your finance department care for a technology choice of the engineering teams? The fucked up thing is your finance department in this scenario, not Charm
