When running multiple VPS instances that need to communicate (a web server and a separate database server, for example), routing that traffic over the public internet is both slower and less secure than using a private network. This guide covers the common approaches.
Why Use a Private Network
- Traffic between your servers never traverses the public internet
- Typically faster and lower latency than public routing
- Reduces exposed attack surface — database ports don't need to be publicly reachable at all
- Often free (no bandwidth charges) between instances in the same provider network
Option 1 — Provider-Native Private Networking
Many VPS providers offer a private networking feature that connects your instances (within the same account/region) via an internal, non-public network interface. Check your provider's control panel for a "Private Network" or "Internal Network" option when provisioning instances.
Once enabled, each server gets a second network interface with a private IP (typically in the 10.x.x.x or 192.168.x.x range):
ip addr showOption 2 — WireGuard VPN Between Servers
If your provider doesn't offer native private networking, or your servers are with different providers, set up a WireGuard tunnel between them — see How to Set Up a WireGuard VPN Server on a Linux VPS, treating one server as the "server" and others as "clients," or configuring a full mesh for more than two servers.
Option 3 — SSH Tunneling (Simple, Temporary Use Cases)
ssh -L 3306:localhost:3306 deploy@DATABASE_SERVER_IPUseful for occasional manual access, but not a substitute for a persistent private network for production traffic.
Configuring Services to Use the Private Network
Once a private network exists, bind services to the private IP instead of the public one:
MySQL example (bind to private IP only):
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnfbind-address = 10.0.0.5Then connect from your application server using that private IP instead of the public one.
Firewall Rules for Private Networking
Even on a private network, apply firewall rules restricting which specific private IPs can reach sensitive services:
sudo ufw allow from 10.0.0.10 to any port 3306Verifying Private Connectivity
ping 10.0.0.5From the application server, targeting the database server's private IP.
Common Architecture: Web + Database Separation
| Server | Public IP Use | Private IP Use |
|---|---|---|
| Web/App Server | Serves HTTP/HTTPS to visitors | Connects to database over private network |
| Database Server | No public exposure needed | Only reachable from app server's private IP |
Common Errors
Private network interface not appearing — confirm private networking was actually enabled for this instance in your provider's control panel, sometimes requiring the instance to be recreated or explicitly attached.
Services still using public IP despite private network being available — explicitly reconfigure the service's bind address and update the application's connection string.
Best Practices
- Never expose a database directly to the public internet if a private network option exists
- Combine private networking with firewall rules restricting exactly which private IPs can connect
- Verify private connectivity works before removing any public-facing fallback access during migration
Continue Reading
- How to Set Up a WireGuard VPN Server on a Linux VPS
- Database Security Checklist: Protecting MySQL, PostgreSQL & MongoDB
- How to Migrate a Database to a New VPS
Browse more articles in Networking & DNS.
