Know what every firewall allows — and never lock yourself out.

Hetzner, DigitalOcean and TransIP today. What you can do differs by provider and is declared rather than assumed: Hetzner and DigitalOcean let you create a firewall and attach it to several servers, TransIP gives each VPS a firewall of its own that cannot be renamed or detached, and OVHcloud has no firewall API at all — its filtering belongs to the IP address rather than the machine, so we leave the subject alone rather than reporting it as off. The integrations page lists what works where.

No. It manages the native firewall your provider already gives you. Rules are written back to the cloud, so what actually runs is the provider’s own firewall — just edited from one place, summarised in a sentence, and checked before it saves. Renaming a firewall renames it at the provider too, so the name is the same everywhere rather than a local nickname.

They are imported as they are when you connect a provider — nothing is dropped or rewritten. Rules the provider manages itself, written in terms of tags, servers, load balancers or Kubernetes clusters rather than addresses, cannot be edited here because our rule shape holds addresses. They are shown, counted and carried through a save untouched, rather than hidden or silently deleted.

It matches the address your session is coming from against the rules you are about to apply, looking only at the ports that are a way back in — SSH and RDP — and checking each address family separately, so an IPv4 0.0.0.0/0 rule is not treated as access for someone connected over IPv6. Port ranges count, so a rule opening 20-30 is recognised as covering SSH. If the change takes your access away, Confirm is blocked until you acknowledge it. While the check is still running, Confirm is dead and says so.

Only if you choose Replace, and you see the resulting rule set before you confirm — the alternative is Append, which adds the template’s rules to what is already there. Built-in templates are read-only; your own can be edited and deleted, and a deleted one is restorable from the recycle bin for fourteen days.

Only inbound rules that are open to any address are considered at all. A rule that opens every port is critical on its own; otherwise it looks for SSH (22), remote desktop (3389) and nine database and cache services — MySQL, PostgreSQL, SQL Server, MongoDB, Redis, Elasticsearch, Memcached, Docker and Kubernetes — each of which is a critical finding. FTP and Telnet are warnings rather than errors: unencrypted, but not a database. Port ranges and comma-separated lists are matched, not just exact ports. Each finding can be dismissed for that check alone.

Yes — bind the rule to a Dynamic IP source and the entry follows your address. Only the entry we wrote is ever changed; every other address in that rule is left alone. It is always a single host route, never a range, and always the address you genuinely connected from rather than one you asked for. The live rules are re-read from the provider before each write, and if the rule we were following has disappeared, the target is flagged and alerted rather than left quietly pointing at a stale address.