Database Firewall & Trusted Sources

TL;DR — By default a new cluster accepts connections from anywhere that can authenticate. Add at least one trusted source on the Firewall tab to restrict access. You can whitelist IP ranges, individual Droplets, Kubernetes clusters, infrastructure tags, or Apps.

Where to Configure

1. Open your cluster → Firewall tab

You'll see two sections:

• Current rules — every trusted source already configured
• Add rule — form to add another

How Firewall Rules Work

The firewall behaves like an allow-list:

• No rules at all → any IP that can authenticate may connect (the cluster is open to the internet behind TLS + password).
• One or more rules → only sources matching at least one rule may connect.

Once you add the first rule, your previous "open" state is replaced — make sure your application's source IPs (or its tag / Droplet / Kubernetes cluster) are in the list before the change takes effect, or you'll be locked out.

💡 You can also remove your public exposure entirely by using the private (VPC) URI and routing all production traffic through the backplane. The firewall still governs public traffic.

Rule Types

IP Address — Common Patterns

You can repeat the rule type to add many CIDRs.

Droplet / Tag — Why You Should Prefer Them

If your app server is a Droplet hosted on EasyCloudify, adding it as a Droplet rule (not its IP) means:

• The rule survives if the Droplet is rebuilt or its public IP changes
• A Tag rule auto-includes any new server with that tag — handy for auto-scaling groups

Add a Rule

1. From the Add rule form:
   • Pick a Type from the dropdown
   • Fill in the Value (IP, CIDR, Droplet ID, tag name, etc.)
2. Click Add

The new rule appears in the list and takes effect immediately.

Delete a Rule

Click the trash icon on the rule row. The change takes effect immediately — any open connection from the now-blocked source is closed on its next query.

Recommended Production Setup

For a typical production app:

1. Add your application servers as Droplet rules (or as a tag like production-web).
2. Add your CI / deployment runner as an IP rule.
3. Add your team's office network and VPN egress as IP rules — for ad-hoc DBA / migration work.
4. Add anything else that legitimately needs access (e.g. a metrics collector, a backup runner, a third-party data warehouse ETL).
5. Do not add 0.0.0.0/0 unless you genuinely need open access for diagnostics — it removes IP enforcement entirely. Prefer adding a temporary rule and removing it when done.

Replicas Inherit Their Own Firewall

Read replicas have independent firewall rules. Configure each replica's Firewall tab separately. This lets you, for example, expose an analytics replica to your data team's office IP without exposing the primary.

Troubleshooting

My app stopped connecting after I added a rule

The first rule replaces the default "allow all" behaviour. Add a rule that covers the app source (Droplet ID, tag, or IP / CIDR). You can re-enable temporary public access by removing all rules.

"Connection refused" but my IP is in the list

• Public IPs change. Run curl ifconfig.me from the host that's blocked, and check it matches a rule.
• If the host is behind a NAT, your public IP is the gateway's egress, not the host's local IP.
• A Droplet rule uses the Droplet's anchor IP; rebuilds can change it briefly — wait a minute and retry.

"Allow all" but still being blocked

Even with no firewall rules, the cluster still requires TLS and the correct password. Check the connection URI's sslmode=require flag and that the password hasn't been rotated.

How do I temporarily allow myself to debug?

Add an IP Address rule with your current public IP, do your work, then delete the rule when done. This is the safest pattern.

Related Guides

• Connect to Your Database
• Database Users & Databases
• Maintenance & Scaling
• Database Log Forwarding