> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rafftechnologies.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Delete a Firewall Group
> Permanently remove a custom Firewall Group from the row menu — the action is blocked while VMs are attached, and any attached VMs need to be rebooted afterward
Updated May 8, 2026
Deleting a Firewall Group permanently removes the rule set from your account. The action is in the row's `⋮` menu and asks for a one-click confirmation — there's no soft-delete or recovery window. Use this when a group's no longer needed (decommissioned service, retired environment, replaced by a different group).
## Before you delete
| Rule | Why |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Detach the group from every VM first** | The Delete action is blocked while any VM has the group attached. The dashboard surfaces this as a disabled menu item or a blocked confirmation. Detach via the VM detail page → Network tab → IP card → **Detach** firewall, on every attached VM, before retrying the delete |
| **The system Default Firewall cannot be deleted** | The `Raff Default Firewall` card has no `⋮` menu and no Delete option. It's immutable. This page only covers Custom Firewall Groups |
| **Plan for a reboot** | Once the group is deleted, every VM it was previously attached to needs a reboot for the change to fully take effect inside the guest. (Detach + delete = two changes; one reboot covers both) |
## 1. Open the row menu
In **Networking → Firewall**, find the group's row in **Your Firewall Groups** and click the `⋮` on the right.
The menu has three actions on a Custom group: **Edit Rules**, **Assign to VM**, and **Delete** (red). Click **Delete**.
## 2. Confirm the delete
The confirmation dialog spells out the cost: *"Are you sure you want to delete **``**? This action cannot be undone."*
Click the red **Delete** to proceed, or **Cancel** to back out.
## What happens after delete
| Effect | Notes |
| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **The group disappears from the Firewall Groups list** | Immediate — no soft-delete, no recovery |
| **Any VM it was attached to has its `Firewall: ` field flip back to `None`** | Detach happens as part of the delete, but only if you didn't detach first |
| **Audit-log entry recorded** | `securitygroup.delete` — captures who deleted, when, the group ID and name. Visible to members with `account.audit.view` |
| **VMs need a reboot** | The platform record updates immediately, but each affected VM keeps using its previous firewall state until reboot |
## Reboot the VMs
If the group was attached to any VMs at delete time, reboot each of them so the guest networking actually drops the old rules. From the VM detail page → **Restart** action button (or `sudo reboot` / `shutdown /r /t 0` from inside the guest).
If you detached the group from all VMs in advance (the recommended path), the reboots can happen on each VM's own schedule — the group is already gone, the VMs just don't yet know it.
## When delete is blocked
If the menu item shows the Delete action greyed or the confirmation refuses to proceed:
| Blocker | Fix |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Group is attached to one or more VMs** | Open each VM's Network tab and Detach the firewall, then retry. The VMs column on the Firewall row tells you the count |
| **Trying to delete the Default Firewall** | Not possible — the system Default is permanent. Use a Custom group with `Deny All` rules attached over it for lockdown patterns |
| **Custom role missing the right permission** | Account permission `account.firewall.delete` (or whichever maps to it in your account's role catalog) is required. Owner and Admin have it; ask the Owner or grant via Custom role |
## Replacing a Firewall Group instead of deleting
If you want to replace one group with another (e.g. swap `web-prod-v1` for `web-prod-v2` on a fleet of VMs) without a window where the VMs are unprotected:
1. **Create the replacement group** with the new rule set
2. **Attach the replacement** to every VM that has the old group — each VM now has both
3. **Reboot every VM** so the new rules take effect alongside the old (the union of rules applies briefly)
4. **Detach the old group** from every VM
5. **Delete the old group** (now unattached, the Delete action is unblocked)
6. **Reboot every VM again** so the old group's rules are dropped
This adds two reboots per VM but means there's no moment when a VM has zero rules. For most workloads, the simpler swap (detach old → attach new → reboot once) is enough — there's a brief moment between detach and attach where only the system Default Firewall applies, which is usually fine.
## What you cannot do today
* **Recover a deleted Firewall Group** — once deleted, it's gone. Recreate from scratch
* **Bulk-delete groups** — one at a time from the row menu (or via the API)
* **Delete the Default Firewall** — system Default is immutable
* **Schedule a delete for later** — delete is immediate
## Related
Edit a group instead of deleting it.
Detach a group as the prerequisite to deleting.
The model behind the rules you're deleting.