> ## Documentation Index > Fetch the complete documentation index at: https://docs.kubestacks.com/llms.txt > Use this file to discover all available pages before exploring further. # Changing things safely > The guard rails around every change KubeStacks makes: permissions up front, the kubectl command shown, dry runs, typed confirmations and undo. KubeStacks can change your clusters: scale, restart, roll back, drain, edit, delete. Each of those goes through the same guard rails, so you always know what's about to happen, and where. A delete dialog in a production cluster, with the PRODUCTION badge, a field to type the name, and the equivalent kubectl command. A delete dialog in a production cluster, with the PRODUCTION badge, a field to type the name, and the equivalent kubectl command. ## Your permissions, up front Before it offers an action, KubeStacks asks the cluster whether your account may do it, with a SelfSubjectAccessReview, the same check `kubectl auth can-i` makes. Actions you can't take stay visible but disabled, and say why: > Your account can't delete pods in shop. The answers are cached for a few minutes. If the cluster can't answer, the action stays enabled and the cluster decides when you try. Either way, nothing gets past RBAC: KubeStacks only ever acts as you, with your own permissions. See [Permissions](/clusters/permissions) for what each feature needs. ## Nothing surprising Every dialog says what it changes and where: * **The object and the cluster.** The header names the object, its kind and namespace, and the cluster it's in. * **The equivalent command.** Under **Equivalent command**, the `kubectl` command that does the same thing, ready to copy. It's a good way to learn kubectl, and a record of what happened. * **What will happen.** Dialogs explain the effect in plain words: how a restart rolls out, which pods a drain evicts, whether a deleted pod comes back. A few of the commands KubeStacks shows: ```bash theme={"theme":{"light":"github-light","dark":"github-dark-default"}} kubectl scale deployment/web --replicas=3 -n shop --context dev kubectl rollout undo deployment/web --to-revision=4 -n shop --context dev kubectl patch cronjob/hello --type=merge -p '{"spec":{"suspend":true}}' -n shop --context dev kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data --context dev kubectl debug -it web-1 --image=busybox:1.37 --container=debugger-ab12c --target=web -n shop --context dev ``` Every change you make also lands in the **Activity** log, with its command. See [Undo and activity](/changes/undo-and-activity). ## Checked by the cluster first Changes you write yourself are checked by the API server before anything is saved: * **YAML edits** are sent as a server-side dry run first, and shown as a diff. Only **Apply** saves them. See [Edit YAML](/changes/yaml). * **New objects** from **Create from YAML** are all dry-run first. If any of them is refused, none is created. See [Create from YAML](/changes/create). * **Helm upgrades and installs** run as `helm … --dry-run=server` first, and show what the manifest would change. See [Upgrade and roll back](/helm/upgrade-and-rollback). ## Changes made meanwhile are caught A YAML edit is saved against the version you started from. If someone changed the object in the meantime, the cluster refuses the save, and KubeStacks says so instead of overwriting their change. **Start over from the latest** loads the current version. ## Hard to do by accident Delete, drain and other destructive dialogs open with the focus on **Cancel**, or on the field where you type the name. A stray ↵ never deletes anything. Deleting a Namespace, Node, PersistentVolume, PersistentVolumeClaim, StorageClass or CustomResourceDefinition asks you to type its name first. These are hard to recover from: a namespace takes everything in it along, and deleting a CRD deletes every object of its kind. For several objects at once, you type what's being done instead, like `delete namespaces`. See [Several at once](/changes/bulk). When a context's name looks like production, every dialog shows a **PRODUCTION** badge next to the cluster's name, and every delete and drain asks you to type the name first, whatever the kind. A name looks like production when it contains `prod`, `production`, `prd` or `live` as a word of its own. These match: `prod`, `eu-prod-1`, `live_cluster`, `gke_acme_us-central1_production`. These don't: `product-demo`, `delivery`. Each delete explains its consequence. Deleting a pod says whether its controller replaces it. Deleting a volume claim warns that the data may go too, depending on the reclaim policy. Deleting a node explains that its pods keep running until its kubelet registers it again. ## Easy to take back Scaling, cordoning, pausing a rollout, suspending, changing images, changing an autoscaler's range and editing labels can be undone from the notification that confirms them. See [Undo and activity](/changes/undo-and-activity). ## Read-only when you want it Turn changes off for one cluster from the cluster switcher, or for every cluster with `KUBESTACKS_READ_ONLY=1`. It isn't only the buttons: the part of KubeStacks that talks to clusters refuses changes too. See [Read-only mode](/changes/read-only). Everything you can do to each kind, and the options each action has. Look without touching, for one cluster or all of them. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.