Saved rules apply to every server using the group within a few seconds, with no restart. Connections that are already open stay open; every new connection follows the new rules. See When the new rules apply below.
Open the Edit dialog
In Networking → Firewall, find the Firewall Group’s row and click the⋮ menu → Edit Rules.
Edit Rules opens only from the Firewall Groups list row: not from the VM detail page (which only shows attach and detach), and not from the system Default Firewall (which is read-only and shows View Rules instead).
The Edit Firewall Group dialog
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.
Common edits
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”, and they do: Save Changes waits until every server using the group has the new rules, usually a few seconds.When the new rules apply
Every server using the group has the new rules when Save Changes finishes. There is no restart and no downtime.- Connections already open stay open. An SSH or RDP session you opened before the change keeps working, even if the new rules would not let it in.
- Every new connection follows the new rules. To make an open session follow them, reconnect, or restart that service on the server.
- A server that is off gets the current rules when it starts.
nmap -p <port> <ip> or a fresh ssh from your laptop. A session that was already open won’t show the change.
If a server did not take the new rules, the dialog says so and names it, for example “The rules are saved, but 1 server (web-1) using this firewall did not apply them.” Save the rules again, or power that server off and on from its detail page.
Editing rules on a group with no VMs attached
If the group has zero VMs in its VMs column, save is instant, and the next VM you attach gets the new rules. This is the right pattern for staging rule changes before production: edit the rules while the group is detached, attach it to a single test VM, check it from outside, then attach it to the rest of the fleet.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
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.