DigitalOcean Cloud Firewall vs UFW: Which to Use for Droplets (2026)

DigitalOcean’s Cloud Firewall is a network-level firewall that operates outside your Droplet, while UFW (Uncomplicated Firewall) is a host-based firewall that runs inside your Droplet.

Let’s see this in action. Imagine you have a web server Droplet.

Scenario: Allowing HTTP Traffic

DigitalOcean Cloud Firewall

Create a Firewall: In the DigitalOcean control panel, navigate to "Networking" -> "Firewalls." Click "Create Firewall."
Name It: Give it a descriptive name, e.g., webserver-firewall.
Add Inbound Rules:
- Type: HTTP
- Protocol: TCP
- Ports: 80
- Sources: You can specify IP addresses, CIDR blocks, or other Droplets. For a public web server, you’d typically leave this as All IPv4 and All IPv6.
- Add another rule for HTTPS:
  - Type: HTTPS
  - Protocol: TCP
  - Ports: 443
  - Sources: All IPv4 and All IPv6.
Add Outbound Rules: By default, Cloud Firewalls usually allow all outbound traffic, which is generally fine for a web server needing to fetch updates or connect to databases. You’d only restrict outbound if you had a very specific security requirement.
Apply to Droplets: Select your webserver-droplet from the list.

Now, any traffic destined for your webserver-droplet on ports 80 or 443 will be allowed by the Cloud Firewall before it even reaches the Droplet’s operating system.

UFW (Uncomplicated Firewall)

SSH into your Droplet:
```
ssh root@your_droplet_ip
```
Install UFW (if not present):
```
apt update && apt install ufw
```
Set Default Policies:
```
ufw default deny incoming
ufw default allow outgoing
```
This is crucial: block everything by default and only allow what you explicitly permit.

Allow SSH (essential!):

ufw allow ssh
# or explicitly: ufw allow 22/tcp

Allow HTTP/HTTPS:

ufw allow http
# or explicitly: ufw allow 80/tcp
ufw allow https
# or explicitly: ufw allow 443/tcp

Enable UFW:
```
ufw enable
```
You’ll be prompted to confirm.
Check Status:
```
ufw status verbose
```
This will show your active rules.

With UFW enabled, the Droplet’s own operating system is now inspecting incoming packets and deciding whether to allow them based on your rules.

The Mental Model: Layers of Defense

Think of it like securing a building.

DigitalOcean Cloud Firewall: This is your perimeter security – the main gate and security guards at the property line. It decides who gets onto the property at all. It’s managed externally and protects multiple buildings (Droplets) simultaneously. It’s great for broad strokes: "allow all web traffic to my web servers," or "block all traffic from this known bad IP range to all my Droplets."
UFW (Host-based Firewall): This is the internal security within each building – the locked doors, internal cameras, and access controls inside the office. It controls what happens once someone is already inside the building. It’s managed individually per Droplet and offers finer-grained control: "allow my web application to connect to the database on port 5432," or "only allow SSH from a specific management IP address to this particular Droplet."

Why Use One Over the Other? Or Both?

Cloud Firewall is Primary for Network Segmentation and Broad Protection:
- Cost-Effective for Multiple Droplets: You can group many Droplets under a single firewall rule set.
- Protects Against Network-Level Attacks: It stops unwanted traffic from even reaching your Droplet’s network interface, reducing load and attack surface.
- Simpler for Common Ports: Allowing HTTP/HTTPS or blocking specific IPs across your fleet is trivial.
- Centralized Management: Apply policies to many Droplets from one place.
UFW is for Granular Control and Application-Specific Rules:
- Application Dependencies: If your application needs to talk to other services on specific ports (e.g., a database on 5432), UFW is the place to manage that from the Droplet’s perspective.
- Loopback Interface: UFW controls traffic on the lo (loopback) interface, which is important for inter-process communication within the Droplet. Cloud Firewalls don’t see this.
- Advanced OS-Level Control: UFW integrates with the kernel’s iptables (or nftables), giving you deep control over packet filtering.
- Specific Droplet Needs: A Droplet might have unique requirements that don’t apply to others, making UFW the better choice for that individual machine.

The Counterintuitive Truth: They Don’t Compete, They Complement

The most common mistake is thinking you have to pick one. In reality, the most robust security posture uses both. The Cloud Firewall acts as the first line of defense, blocking unwanted traffic at the network edge. UFW then acts as the second line, providing granular control within the Droplet and securing specific application ports or internal communication. You wouldn’t just lock the front door of your house; you’d also lock individual room doors.

Example: A Multi-Tier Application

Imagine a web application with a frontend Droplet and a backend database Droplet.

Cloud Firewall:
- Apply a firewall to the frontend Droplet allowing HTTP (80) and HTTPS (443) from All IPv4/IPv6.
- Apply a firewall to the backend database Droplet allowing only traffic on PostgreSQL (5432) from the specific IP address range of your frontend Droplet(s).
UFW on Frontend Droplet:
- Allow SSH (22) from your management IP.
- Allow HTTP (80) and HTTPS (443) from Anywhere.
- Crucially, allow TCP on port 5432 only to the IP address of your backend database Droplet.
UFW on Backend Droplet:
- Allow SSH (22) from your management IP.
- Allow PostgreSQL (5432) only from the IP address of your frontend Droplet.

In this setup, the Cloud Firewall prevents any unauthorized access to the database from the internet, and even restricts it to only the frontend Droplet at the network level. UFW on the frontend then ensures that only the database port is accessible from that Droplet, and UFW on the backend provides the final layer of defense, again only allowing connections from the frontend Droplet.

The next step is often understanding how to manage these rules at scale using infrastructure-as-code tools or DigitalOcean’s API.