Updated May 8, 2026 Edit Firewall Group is how you change anything about an existing custom Firewall Group — its name, description, inbound rules, or outbound rules. The dialog is the same one used to create the group, just prefilled with the current rule set; there’s no separate read-only view. Use this page to modify a group that’s already attached to one or more VMs without detaching it.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.
Open the Edit dialog
In Networking → Firewall, find the Firewall Group’s row and click the⋮ menu → Edit Rules.
You can also reach Edit Rules from the API Keys list — wait, scratch that. Edit Rules opens only from the Firewall Groups list row — not from the VM detail page (which only shows attach/detach), and not from the system Default Firewall (which is read-only and shows View Rules instead).
The Edit Firewall Group dialog
| Create Firewall Group | Edit Firewall Group | |
|---|---|---|
| Title | ”Create Firewall Group" | "Edit Firewall Group” |
| Subtitle | ”Define rules to control inbound and outbound traffic on public interfaces” | Modify rules for <name>. Changes apply immediately to all attached VMs. |
| Name | Empty placeholder | Prefilled with current name; editable |
| Description | Empty placeholder | Prefilled with current description; editable |
| Start from template | Visible — pre-fills rules | Not shown — would clobber existing rules |
| Inbound / Outbound rules | Empty rows | All current rows visible; add, remove, or edit any |
| Save button | Create Firewall Group | Save Changes |
Common edits
| Goal | What to change |
|---|---|
| Lock SSH down to your office IP | Find the inbound TCP 22 row, change the Source field from 0.0.0.0/0 to <office-ip>/32 |
| Open a new port for a service | + Add an Inbound row with Protocol TCP, Port <your-port>, Source 0.0.0.0/0 (or tighter) |
| Stop allowing all outbound | Remove the catch-all ALL / All ports / 0.0.0.0/0 Outbound row, then add specific outbound rules (DNS UDP 53, NTP UDP 123, your package mirrors, etc.) |
| Change protocol on an existing rule | Click the Protocol dropdown on the row and switch — the Ports field follows the protocol’s format |
| Tighten a CIDR | Edit the Source field on the row (e.g. 0.0.0.0/0 → 203.0.113.0/24) |
| Rename the group | Edit the Name field; the change applies to the row label, the audit log, and anywhere the group is referenced |
Click Save Changes
Save persists the new rule set to the platform record. The button is greyed out and the dialog stays open if any row fails validation (bad port format, invalid CIDR, system-blocked port, name conflict) — the row with the error highlights inline, fix and retry. The dialog’s subtitle says “Changes apply immediately to all attached VMs” — that’s accurate at the platform record level: the rules on Raff’s side update in seconds and any new connections evaluate against them. Existing connections aren’t dropped. But the guest VM still needs to reboot before its in-guest networking sees the new rules — see below.A VM reboot is required after saving
This is the rule that catches every team the first time: To roll a fleet of VMs through the reboot:| VMs attached | Approach |
|---|---|
| One VM | Restart from the VM detail page → Restart action button. Total downtime: typically a minute |
| Two or three VMs | Restart in series — wait for each to come back before rebooting the next, so any service the group covers stays available on at least one VM |
| Many VMs (a fleet) | Plan a maintenance window, or use a rolling-restart pattern: drain a VM from your load balancer, reboot, re-add. Repeat per VM |
Editing rules on a group with no VMs attached
If the group has zero VMs in its VMs column, save is instant and there’s nothing to reboot — the group’s rule set updates and the next VM you attach will get the new rules at attach-then-reboot time. This is the right pattern for staging rule changes before production: edit the rules while the group is detached, attach to a single test VM, reboot, validate, then attach to the rest of the fleet (each one rebooted in turn).Audit logging
Every edit produces an audit-log entry (in<resource>.<verb> form, e.g. securitygroup.update) capturing:
- Who made the change (member ID + name, or API key ID)
- When
- The group ID and name
- A diff of the rules — what was added, what was removed
account.audit.view permission (Owner and Admin by default) can read the entries. Useful for “why did port 8080 stop working last Tuesday?” investigations.
What you cannot do via Edit
| Action | Available via |
|---|---|
| Change the group’s scope (account-level only — this product doesn’t have project-scoped firewall groups today) | n/a |
| Convert a Custom group into a System role | n/a — System roles ship with Raff and are immutable |
| Edit the Default Firewall | The system Default is read-only — view its rules with the View Rules action on the Default card |
| Bulk-import rules from a JSON / YAML | Use the Update Firewall API and pipe a JSON body. The dashboard is row-by-row only |
Related
Add rules
Port and IP format reference for the rule rows.
Inbound vs outbound
The rule model and what the system Default blocks.
Attach to a VM
Apply the edited group to a VM’s public IP.