DigitalOcean Firewall: Free Cloud-Level Protection, Zero Config to Lock Down Every Droplet

You know that feeling when you spin up a fresh Droplet, ssh in, and then immediately start wondering who else on the internet might be knocking on port 22 right now? I had that feeling more times than I care to admit. For a long time, my answer was the same as everyone else's: install UFW, copy-paste a few rules from a tutorial, hope for the best. Then I actually looked at the Networking tab in the control panel and realized DigitalOcean has been handing out a free, network-level firewall the whole time, and I'd been ignoring it like a forgotten gift card.

This is the part of the story where I tell you what the DigitalOcean firewall actually is, why it's quietly better than fighting with iptables at 2am, and how to set it up without locking yourself out of your own server. If you've never touched it, you can have your first rule set live in about five minutes — and yes, it costs nothing on top of whatever Droplet you're already paying for. 👉 Open a DigitalOcean account and grab the free Cloud Firewalls along with it.

What the DigitalOcean firewall actually is

The DigitalOcean Cloud Firewall is a stateful, network-based firewall service that sits in front of your Droplets. "Stateful" is the important word here. It remembers the connections you've allowed, so when your server reaches out to an API and the response comes flying back, the firewall lets it through instead of treating it like an attack. You don't have to write symmetric rules for every conversation.

"Network-based" is the other important word. Unlike UFW or iptables, which live inside the operating system of each Droplet, the Cloud Firewall stops traffic before it ever reaches your server. The packet gets dropped at the edge. Your Droplet never spends a CPU cycle on it. And because the firewall lives outside the box, you can manage one set of rules and apply them across a whole fleet of Droplets without logging into a single one of them.

The default posture is also the one security people keep telling you to adopt but nobody actually does until they get burned: deny everything inbound, then open only what you need. If you configure zero inbound rules, nothing comes in. Period. You have to explicitly allow traffic, which is the opposite of the "everything open until I close it" model that gets people in trouble.

The one thing that finally made me switch from UFW

For years I ran UFW on every box. It works. It's fine. The problem shows up the moment you have more than one Droplet.

You build a new web server, you forget to copy the firewall script, you forget to allow your monitoring agent, you forget that the database port should only be reachable from the app server's private IP. Six months later you're cleaning up and you find a Droplet you forgot existed with port 3306 open to the entire planet.

With the DigitalOcean firewall, the rules live in the control panel, not on the box. You define them once, you tag your Droplets, and any new Droplet that gets the tag is instantly protected by the same ruleset. New web server? Tag it web. It's now behind the web firewall. Done. The firewall rules automatically inherit and apply. You can't forget, because the rule was never something you had to remember to run on the new box.

And since the firewall is separate from anything running on the Droplet, you can also keep UFW running for an extra layer if you're the belt-and-suspenders type. Just make sure the two don't conflict — if the Cloud Firewall allows port 22 from your office IP but UFW allows port 22 from anywhere, the more restrictive one wins at the network edge, but the looser one is still sitting there inside the box. Worth cleaning up.

The August 2026 update that changed the game: deny rules

For a long time, the Cloud Firewall only did "allow" rules. That sounds fine until you have a specific bad IP you want to block while keeping the rest of the internet able to reach your site. You'd have to allow-list everything except the bad guy, which is impractical when the bad guy keeps changing addresses.

As of August 2026, DigitalOcean added a proper deny action to firewall rules. You can now write rules that explicitly block traffic from a source — say, a known malicious IP or a sketchy CIDR range — while broader allow rules keep the rest of your service open to the world. Deny rules take precedence over allow rules, including across multiple firewalls applied to the same Droplet. If anything matches a deny, it's gone. That finally makes the Cloud Firewall behave like a grown-up perimeter firewall instead of just an allow-list.

A typical hardened setup now looks like this: deny everything from a list of bad IPs and ranges, then allow HTTPS from all IPv4 and IPv6, then allow SSH only from your office or a bastion host. The deny rules cut off the noise first, the allow rules open the doors you actually want open.

How to actually configure it (without locking yourself out)

The fastest path is the control panel. Open the Networking menu, click Firewalls, click the firewall name, and you land on the Rules tab. From there:

• Click Add inbound rule or Add outbound rule.

• Either pick a preset (SSH, HTTP, HTTPS, MySQL, etc., which auto-fills protocol and port) or choose Custom and define the protocol, port range, source, and action yourself.

• For sources, you can use individual IPs, CIDR ranges like 10.128.0.0/16, the keywords All IPv4 / All IPv6, or references to other resources by name — Droplets, Load Balancers, VPCs, Kubernetes clusters, or resource tags.

• Set the action to allow or deny. Default is allow.

• Click save.

The thing I always tell people: set up your SSH allow rule before you apply the firewall to a production Droplet you care about. Allow port 22 from your IP (or your VPN range) first. Then attach the firewall. Otherwise you will find out the hard way that "deny by default" includes you.

If you'd rather script it, you can do the same things with doctl, the official CLI, or the REST API. Note that doctl doesn't yet support the new action field, so if you want to create deny rules programmatically you'll need to hit the API directly. A minimal API call to add a deny rule blocking all traffic from 203.0.113.5 looks like:

bash
curl -X POST
-H "Content-Type: application/json"
-H "Authorization: Bearer $DIGITALOCEAN_TOKEN"
-d '{"inbound_rules": [{"protocol": "all", "ports": "0", "sources": {"addresses": ["203.0.113.5"]}, "action": "deny"}]}'
"https://api.digitalocean.com/v2/firewalls/$FIREWALL_ID/rules"

Notice protocol: "all" — that's only valid on deny rules. Allow rules have to specify tcp, udp, or icmp explicitly. Deny rules are the only ones that can match across every protocol and port at once.

Tags: the actual reason this scales

The single best feature of the DigitalOcean firewall, in my opinion, is tags. You don't apply rules to a Droplet. You apply rules to a tag, and any Droplet carrying that tag inherits the rules.

Want a production-web policy? Tag your three web servers production-web, attach the firewall to that tag, and you're done. Spin up a fourth web server next month, tag it production-web, and it's instantly behind the same firewall — no setup, no forgotten rules, no SSH required. This is the part that turns firewall management from "per-server homework" into "policy."

There are limits worth knowing about so you don't hit a wall at 2am:

• Up to 10 Droplets per firewall and 5 tags per firewall. If you have more than 10 Droplets that share a policy, use a tag instead of listing them.

• Up to 50 total inbound plus outbound rules per firewall.

• Up to 1,000 entries total across the Sources and Destinations fields of all deny rules on a firewall. If you need to block more than 1,000 individual IPs, use tags or CIDR ranges instead of one-by-one entries.

• You can't attach a Cloud Firewall to a Load Balancer. The LB is its own thing with its own rules.

• The firewall affects both public and VPC traffic, so if you want different rules for private vs public, you have to specify the IP ranges explicitly.

• Because traffic is dropped at the network edge, there are no traffic logs available. If you need full packet visibility, you'll want a host-based tool alongside it.

• Existing connections aren't killed when you add or change rules — only new matching traffic is affected. Good to know when you're tightening SSH access mid-session.

• During a live migration, connection state doesn't transfer, so active connections reset and clients need to reconnect. Not a daily concern, but it explains the occasional mysterious dropped session.

Cloud Firewall vs. host firewall: which one when

The honest answer is they're complementary, not competitors.

The Cloud Firewall is the right tool for perimeter control: who can reach which ports from the internet, applied consistently across a fleet, managed centrally, free. It's the bouncer at the door.

A host-based firewall like UFW or nftables is the right tool for things that need to live inside the box: restricting which local users can bind to which ports, handling rules that change based on what's running on that specific machine, or defense-in-depth if you don't fully trust the network layer.

For most small-to-medium setups — a web server, a database, a couple of workers — the Cloud Firewall alone is plenty. For a regulated environment or a box that might be on a hostile network, run both and make sure they agree. The Cloud Firewall is the broad stroke, UFW is the detail work.

One gotcha worth flagging: if your Droplet was built from a custom image, it gets its network config via DHCP on UDP port 67. If you put that Droplet behind a Cloud Firewall, you need an outbound rule allowing UDP 67 or the box can't properly configure networking. Easy to forget because the official images handle this for you.

What this costs (and the honest pricing rundown)

Here's the part nobody actually puts in firewall tutorials, but it matters because the firewall doesn't exist in a vacuum — it protects Droplets, and Droplets cost money. Cloud Firewalls themselves are free, full stop, no asterisks. You pay nothing extra for the firewall service regardless of how many rules or Droplets you put behind it.

What you pay for are the Droplets the firewall protects. As of January 1, 2026, DigitalOcean moved to per-second billing on Droplets (60-second minimum, or $0.01, whichever is higher), which is great for short-lived workloads like CI jobs and batch runs. The monthly cap means you'll never pay more than the listed monthly price even if you forget to destroy something.

A quick rundown of the main Droplet families and who they're for, since the firewall sits in front of all of them equally:

Basic Droplets (shared CPU) — Starting at $4/month for 1 vCPU, 512 MiB RAM, 10 GiB SSD, 500 GiB outbound transfer. Scales up through $6, $12, $18, $24, $48, $96 monthly options up to 8 vCPUs / 16 GiB. The right choice for low-traffic web servers, blogs, dev/test boxes, small databases, microservices. This is the tier that pairs most naturally with a single Cloud Firewall for someone just securing their first server. 👉 Start with the $4 Basic Droplet and add your free Cloud Firewall.

General Purpose Droplets (dedicated CPU, ~4 GB RAM per vCPU) — Starting at $63/month for 2 vCPUs, 8 GiB RAM, 25 GiB SSD, 4,000 GiB transfer, scaling up to $1,260/month for 40 vCPUs. The default production choice for medium-to-high-traffic web servers, e-commerce, mid-size databases, SaaS apps. Premium variants add NVMe SSDs and up to 10 Gbps outbound.

CPU-Optimized Droplets (dedicated CPU, ~2 GB RAM per vCPU) — Starting at $42/month for 2 vCPUs, 4 GiB RAM, scaling to $1,008/month for 48 vCPUs. Built for video streaming, gaming servers, AI/ML inference, heavy CI/CD, anything CPU-bound. Premium variants again add NVMe and 10 Gbps networking.

Memory-Optimized Droplets (8 GiB RAM per vCPU, NVMe) — Starting at $84/month for 2 vCPUs / 16 GiB, up to $1,344/month for 32 vCPUs / 256 GiB. For high-performance SQL/NoSQL databases, in-memory caches like Redis, real-time big data, JVM-heavy apps that crash without headroom.

Storage-Optimized Droplets (NVMe, large local disk) — Starting at $131/month for 2 vCPUs / 16 GiB / 300 GiB NVMe, up to $2,096/month for 32 vCPUs / 256 GiB / 4.69 TiB. For large NoSQL clusters like MongoDB and Elasticsearch, monitoring stacks like Prometheus+Grafana, data warehouses.

Every Droplet, regardless of tier, gets the Cloud Firewall for free, plus 500 GiB+ of outbound transfer per month and free inbound, plus free DDoS protection on applicable resources. So the firewall decision isn't a budget decision — it's just "do you want to be protected or not."

For new accounts, DigitalOcean historically runs a promotional credit offer for first-time users — commonly cited as $200 in credit valid for 60 days — which is more than enough to spin up a Basic Droplet, attach a Cloud Firewall, lock down SSH, open 80/443, and experiment with deny rules until you're comfortable. The exact offer can change, so check the signup page for what's currently running. 👉 Claim the new-user credit and set up your first secured Droplet.

My actual setup, in case it's useful

I keep two firewalls per environment these days. One is edge-allow, which permits 22 from my bastion's IP, 80 and 443 from All IPv4/All IPv6, and allows outbound TCP 53, 80, 443, 5432 (only to internal DB tags). The other is edge-deny, with deny rules for a small list of known-bad IPs and one or two CIDRs I've learned to distrust. Both firewalls get attached to the same production-web tag. Because deny rules take precedence across combined rulesets, the bad traffic gets dropped at the edge even though edge-allow would technically let it through, and legitimate users hit the allow rules normally.

I also keep UFW on the database Droplets, not for the perimeter but for inside-VPC hygiene — only the app servers' private IPs can reach 5432, full stop. Defense in depth, and it's saved me from at least one misconfigured app server that would otherwise have been able to talk to the wrong database.

The whole thing took maybe an afternoon to set up the first time, and now spinning up a new service is: build the Droplet, tag it, done. The firewall just happens.

The part I'd actually tell a friend

If you take nothing else from this: the DigitalOcean firewall is free, network-level, stateful, supports deny rules as of August 2026, and applies itself automatically via tags. There is essentially no scenario where a Droplet should be sitting on the open internet without one. The five minutes you spend setting up an allow rule for SSH and a deny rule for the IPs you don't like is the cheapest security upgrade you'll ever make.

And if you've been managing per-server UFW rules by hand for years like I was, give the Cloud Firewall a real try. You'll stop missing it the moment you tag your first new Droplet and watch it inherit the rules without you doing anything. 👉 Set up your Cloud Firewall on a new DigitalOcean Droplet today.