Investigation and mutation are different jobs. You may open a Deployment because you want to understand its Pods, then discover that the next button in the drawer would change the cluster. A safe Kubernetes GUI should make that boundary visible before a click can cross it.
Vastanex starts each cluster in read-only mode. You can connect, browse live lists and inspect a detail drawer without first granting the app permission to perform a write. The switch is per cluster, and the app keeps Kubernetes RBAC as the final authority.
See the read-only state before you act
A Deployment keeps a set number of copies of your app running and replaces any that stop. That makes it a useful object to inspect when you are checking a rollout, but also a tempting place to click Scale, Restart or Delete. The initial state should not make those actions look ready when the operator has only asked to look around.
The web Deployment in this real app capture remains readable. Its drawer shows the raw object and the Delete control, but the control is disabled. The reason is visible: Allow changes is off, and the status bar carries the Read-only state. That wording is more useful than a silent grey button because it answers the immediate question, “Why can I not do this?”
Read-only is a starting decision, not a substitute for access control. When you intentionally want to perform a safe change, you can enable Allow changes for the selected cluster. The app then checks whether the connected identity may perform the particular action. A switch cannot turn a forbidden Kubernetes request into an allowed one.
Make a destructive action state its consequence
Even after the operator enables changes and has permission, a destructive action should slow down enough to be read. Vastanex opens a confirmation dialog that names the target, describes the consequence and provides a cancel path. Deleting also requires the object name to be typed exactly.
This dialog is deliberately cancelled. The capture proves the conversation the app has with the operator; it does not change the demo cluster. The sentence “This cannot be undone” is not hidden behind a technical details disclosure. The exact name field makes an accidental confirmation harder, while the raw request remains available for someone who wants to inspect what would be sent.
The same pattern applies to less destructive changes. A scale confirmation explains how many copies will run. Restart, eviction and other actions have their own consequence text. Confirmation is not a promise that Kubernetes will accept the request or that a rollout will finish. It is the last clear checkpoint before the app asks the API server to do something.
Let RBAC say no
The app-level switch and the cluster permission answer different questions. Allow changes answers, “Has this operator chosen to make writes available in this app?” RBAC answers, “May this identity perform this verb on this resource?” Both need to allow an action.
The restricted-context capture shows the useful failure state. Reads still work: the operator can open the web Deployment and inspect it. After Allow changes is enabled, Delete remains disabled and its gate explains that the cluster identity is forbidden. The app does not present the object as unavailable just because the identity cannot write it.
That distinction is useful in a team. A read-only account can still help someone gather evidence, compare a rollout or pass a precise object name to a cluster administrator. A user with broader access can choose to enable changes for the right context and then see the same permission-aware controls. The interface makes the scope of that choice visible rather than treating a global “admin mode” as the answer.
What it does not do
Read-only by default does not mean Vastanex can make a production cluster safe by itself. It is one guard in a chain that includes the selected kubeconfig context, the Kubernetes API server and its RBAC rules. An operator can enable changes, and a permitted action can still have consequences that require careful review.
The app does not bypass RBAC, guarantee that a controller will finish a rollout or turn a request into proof that the cluster changed as intended. The confirmation dialog is cancelled in these screenshots, and website captures never apply a mutation. The product also does not imply that every plan has different enforced feature locks; current commercial terms are still being finalised.
Read the Problems-first workflow to see why the object is opened before an action is considered, then download Vastanex to try the read-only desktop flow on a cluster you choose.