Open Edit Firewall Group from the row menu to change a group’s name, description, inbound rules, or outbound rules — same dialog as Create, just prefilled with the existing rule set
Updated May 8, 2026Edit 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.
A VM reboot is required for rule changes to take effect inside the guest. The platform’s record updates immediately, but the guest network stack only picks up the new rules at boot. Reboot every VM the group is attached to after saving — see VM reboot is required below.
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).
”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
The rule-row controls are identical — Protocol dropdown (TCP/UDP/ICMP/ALL), Ports field (single, comma list, colon range, or empty), Source/Destination CIDR, the trash icon to remove a row, the + Add button to insert a new row. The validation, the 40-rule cap per direction, and the system-default-port sanitization all behave the same way as on Create. See Add rules for the format reference.
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.
This is the rule that catches every team the first time:
Save Changes alone is not enough — every attached VM must be rebooted for the new rules to take effect inside the guest.The platform writes the new rule set immediately, but the guest’s network stack picks up the firewall only at boot. Until you reboot, the VM keeps running with its previous firewall state — you’ll see the new rules on the dashboard but not feel them in iptables -L / Test-NetConnection.
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
If you’re behind a load balancer or DNS-round-robin, rolling-restart works without user-visible downtime. If you’re not, schedule the reboot during a low-traffic window.
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).
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 members with account.audit.view permission (Owner and Admin by default) can read the entries. Useful for “why did port 8080 stop working last Tuesday?” investigations.
