Firewall as a policy, not a resource
In Flui the firewall is not “a thing you create and edit”. It is a derived view of the cluster’s needs — installed when the cluster is created, attached to every node automatically, kept in sync as the cluster’s shape changes, and built around a policy the user states rather than a rule list the user maintains.
This chapter is about that inversion of ownership: Flui owns the firewall and its rules; the user states intent (which IPs are allowed in for operator access), and the rest falls out.
The default policy
Every Flui cluster that lives on a provider with a managed firewall comes up with the same baseline policy:
| Port | Source | Reason |
|---|---|---|
22/tcp (SSH) | a user-controlled allow-list (auto-detected operator IP, or values you pass) | Operator access for bootstrap and diagnostics |
80/tcp, 443/tcp (HTTP, HTTPS) | open to the world | Public ingress for the cluster’s applications and platform components |
| Outbound | allow-all | Apps need to reach external services, registries, ACME |
Everything else stays closed at the public perimeter. The cluster runtime and the platform components keep talking to each other on the private network without ever needing a firewall hole — see VNets and subnets, abstracted.
The default exists so the cluster comes up usable out of the box,
with the SSH allow-list bound to your workstation and everything
else closed. The everyday operation on this policy is updating
that allow-list — typically when your IP changes, or when more
operators need access — through flui env update-firewall, which
takes an IP, a comma-separated list of CIDRs, or no argument at
all (in which case it auto-detects your current public address).
When the default policy is not what you need, the dashboard exposes a full firewall editor: rules can be added, modified or removed directly from the cluster’s Firewall tab, and the API accepts the same operations. The default is a sensible starting point, not a fixed shape.
A note of caution that follows from the editor’s existence: a misconfigured firewall — a missing SSH rule, an unintended port exposed to the world, a stray block on the ACME challenge path — is one of the most common ways to lock a cluster out of its operator or out of certificate renewal. The default exists to avoid that class of mistakes; deviating from it is fine as long as you keep those three lines (SSH, public ingress, outbound for ACME) in mind.
How the firewall tracks the cluster
The firewall is born with the cluster and lives as long as the cluster lives. Three moments matter:
- At cluster creation, the firewall is provisioned before — or in the same step as — the master server, so the master is never briefly reachable on the public internet without protection.
- When a worker is added, the existing firewall is attached to it before the node boots. There is no window in which a new node sits exposed.
- When a worker is removed, the server is deleted at the provider and the firewall’s record of attached nodes is updated accordingly. The firewall itself stays in place for the remaining nodes.
The user never has to think about any of this: it is part of the node add/remove flow described in Nodes and cluster topology.
The provider abstraction
The firewall is one of the dimensions Flui’s provider abstraction covers. Each integrated provider implements the same Flui-side contract — create, update, attach, detach — and the differences between providers in rule shape and direction semantics are absorbed by the provider integration. The cluster above sees one neutral firewall model.
Where this chapter goes from here
- Creating a cluster from zero — where the firewall is born.
- VNets and subnets, abstracted — the private network the firewall does not filter.
- How Flui works across providers — why firewall capability is one of the dimensions a provider can expose or lack.