DigitalOcean Databases don’t just grant access to anyone who can ping the IP; you can (and should) restrict access to specific IP addresses or ranges. This is your first line of defense for sensitive data.
Let’s see it in action. Imagine you have a PostgreSQL database my-db in the nyc1 datacenter. You want to allow access only from your office IP 192.0.2.100 and a staging server 203.0.113.50.
First, you’d connect to your DigitalOcean control panel. Navigate to "Databases," select your database cluster, and then go to the "Settings" tab. Under the "Trusted Sources" section, you’ll see an "Edit" button. Clicking this allows you to add or remove IP addresses.
Here’s what adding those sources would look like in the UI, conceptually:
- Add Source 1:
- IP Address/CIDR:
192.0.2.100 - Description: Office Network
- IP Address/CIDR:
- Add Source 2:
- IP Address/CIDR:
203.0.113.50 - Description: Staging Server
- IP Address/CIDR:
After saving, only connections originating from 192.0.2.100 or 203.0.113.50 will be able to establish a connection to your database. Any other IP attempting to connect will be silently dropped or receive a connection refused error at the network level.
This mechanism works by configuring the underlying firewall rules for the database node itself. DigitalOcean’s managed database service abstracts away the complexity of managing iptables or cloud firewalls directly; you simply declare your trusted sources, and the platform enforces them. It’s a crucial step for isolating your database from the public internet, especially if you’re not using a private network.
The primary problem this solves is preventing unauthorized access. Without trusted sources, your database endpoint is potentially exposed to the entire internet. Anyone who knows the database hostname and port could attempt to brute-force credentials or exploit vulnerabilities. By restricting access to known, legitimate IP addresses, you drastically reduce the attack surface. This is particularly important for production databases containing sensitive customer data.
You can also use CIDR notation to specify ranges. For example, if your office has a block of IPs from 192.0.2.0 to 192.0.2.255, you’d enter 192.0.2.0/24. This is more efficient than listing individual IPs and easier to manage if your IP allocation changes.
DigitalOcean also allows you to configure trusted sources on a per-database basis within a cluster if you have multiple databases with different access requirements, although this is less common. The standard practice is to apply trusted sources at the cluster level.
Remember that your application servers and any other services that need to connect to the database must have their outbound IP addresses listed in the trusted sources. If your application runs on DigitalOcean Droplets within the same VPC network, you can use the private IP addresses of those Droplets and enable VPC network access for your database. This is generally more secure than exposing your database to the public internet and using public IPs. To enable VPC network access, you’d find the "VPC Network" section in your database cluster’s settings and toggle it on, then add the private IP addresses of your Droplets to the trusted sources.
A common pitfall is forgetting to update trusted sources when your application’s IP address changes, such as when migrating servers or deploying new instances. This can lead to legitimate applications being locked out. Always test connectivity from your application environment after making changes to trusted sources.
If you’re using a managed Kubernetes cluster, you’ll need to add the Kubernetes node IPs or the IP of your LoadBalancer/Ingress controller to the trusted sources. For more granular control within Kubernetes, you might consider using a Database Access Control List (ACL) solution or a proxy within your cluster.
The next step in securing your database is often configuring SSL/TLS for encrypted connections.