Most small cloud deployments start with every server holding a public IP and talking to every other server over the internet. It works, and it is the reason so many databases end up exposed. Good network hygiene on a new account comes down to a few habits: internal traffic stays on a private network, exactly one thing faces the public, firewalls deny by default, and public addresses are tracked like any other asset. This guide explains each habit and how it maps onto OVHcloud and BinaryLane, two providers whose listings on the marketplace are aimed at self-managed infrastructure.
Private networks first
A private network is an address range that only your own resources can reach. Application servers talk to databases and caches across it, and nothing on the internet can route to those addresses. OVHcloud provides this through vRack, which can connect resources across data centers and product lines. BinaryLane offers Virtual Private Cloud features with custom private address ranges and controlled internet access.
The rule is simple: if two of your servers talk to each other, they do it over the private network. The public interface on internal servers should carry nothing but administrative access, and ideally not even that.
- Create the private network before the first server, so nothing is retrofitted.
- Put databases, queues and caches on private addresses only.
- Use private DNS names internally so a re-addressed server does not break configuration.
One public entry point
A load balancer or a single reverse proxy should be the only resource with an open public port for application traffic. Everything behind it listens on the private network. This shrinks the attack surface to one well-understood component, makes TLS termination a single configuration, and means adding a second application server requires no firewall change.
Both OVHcloud and BinaryLane offer load balancers. For very small deployments, a single small instance running a reverse proxy does the same job and can be replaced by a managed balancer later.
Firewalls: deny by default
Provider firewalls sit in front of the instance and filter traffic before it arrives, which protects even a misconfigured server. BinaryLane’s external firewall rules block or allow ports before traffic reaches the instance; OVHcloud offers network-level firewalling alongside the host firewall. Start from deny-all and open only what each role needs.
| Role | Inbound from internet | Inbound from private network |
|---|---|---|
| Load balancer or proxy | Ports 80 and 443 | Health checks |
| Application server | None | Application port from the balancer |
| Database | None | Database port from application servers only |
| Bastion or admin host | SSH from a fixed allow list | SSH to everything |
Keep a host-level firewall as well. The provider firewall protects against misconfiguration on the host; the host firewall protects against misconfiguration in the console. Together they mean one mistake does not become an exposure.
Administrative access
Restrict SSH and RDP to a bastion host or a VPN, and restrict that to a short allow list of source addresses. Never leave port 22 open to the world “temporarily.” Key-based authentication only, and rotate keys when people leave, as described in the key rotation guide.
Public IPs are assets
Every public IPv4 address on an account is something to track, and on most providers something billed. Reserved or floating IPs that are not attached to anything still cost money and still appear in DNS records that point somewhere they should not. Keep an inventory: which address, which resource, which DNS name, who owns it. The monthly cleanup routine includes a pass over idle addresses for exactly this reason.
Enable IPv6 where the provider supports it. BinaryLane provides IPv4 and IPv6 connectivity as standard, and dual-stack from day one avoids a painful migration later.
Where the listed accounts fit
The marketplace lists an OVH vCPU34 Account and an Binarylane Open 25 Port Account. Both providers give root access and expect the account holder to design the network, which makes the habits above the difference between a tidy deployment and an exposed one. Open ports on any listing should be treated as capability, not configuration: the firewall still starts closed and opens only for the roles that need it, and every service must operate within the provider’s acceptable-use terms.
A first-week checklist
- Create the private network and put every server on it.
- Give only the load balancer or proxy a public application port.
- Apply deny-by-default provider and host firewalls per role.
- Route administrative access through a bastion or VPN with an allow list.
- Inventory every public IP and its DNS record.
- Enable IPv6 alongside IPv4.
None of this costs more than a few hours, and it is far easier on a new account than on one that has grown by accident. For the security controls that sit above the network layer, see the security baseline.
