Update rules in a Firewall Group

_{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.

​

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

Edit dialog vs Create dialog — what’s different: 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” — 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: 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.

​

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 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.

​

What you cannot do via Edit

​

Related