Skip to main content
A VPC is a private network for your instances. Instances attached to the same VPC reach each other over private addresses, without their traffic leaving for the public internet. The usual reason to want one: a database that should be reachable by your application server and by nothing else. Instead of exposing port 3306 publicly and defending it, you do not expose it at all.
Prerequisites
  • An OnetSolutions account with a project
  • At least one instance, or the intention to create some

​
Creating a VPC

1

Open VPC

In the console, go to Compute and open the VPC tab.
2

Start creating

Click Create VPC.
3

Name the network

Fill in Network Name — something describing its role, such as prod-backend.
4

Choose the CIDR block

Enter a private IP range in CIDR Block, for example 10.0.0.0/16. This defines the addresses instances on this network receive.
5

Create

Confirm. The network appears in the list with its status.
The CIDR block and the location cannot be changed after creation. Both are fixed for the life of the VPC — getting them wrong means deleting the network and starting again, which means detaching every instance on it first.

​
Choosing a CIDR Block

Use a range reserved for private networks. Three blocks are set aside for this: A /16 gives you 65,536 addresses, which is generous for most projects and leaves room to grow. There is no benefit in being tight here.
Pick a range that does not collide with anything else you connect to — your office network, a VPN, or Docker’s default bridge. Overlapping ranges cause routing problems that are tedious to diagnose after the fact, and the CIDR cannot be changed later.

​
Attaching an Instance

1

Open the instance

In Compute, open the instance you want to attach.
2

Go to its VPC tab

Select the VPC section for that instance.
3

Associate

Pick the network from Available VPCs and click Associate.
A VPC belongs to a location, and only instances in that same location can join it. If the list is empty, the instance is in a location where you have no VPC yet.
To detach later, use Dissociate on the same screen. The instance immediately loses access to the other instances on that private network, so check nothing depends on it first.

​
Using the Private Network

Once two instances share a VPC, they reach each other over their private addresses. Find the private address on the instance:
Then bind services to the private address instead of every interface. For PostgreSQL:
For MySQL or MariaDB:
Binding to a private address is what actually closes the service off. A database listening on 0.0.0.0 is reachable from the internet whether or not a VPC exists — the VPC adds a private path, it does not remove the public one.
Verify what is listening where:
Anything showing 0.0.0.0: is exposed on the public interface.

​
VPC and Firewall

The two solve different problems and work together. The VPC provides a private path between instances; the firewall controls what may travel over it and what may reach the instance publicly. A private network is not by itself a permission system — every instance attached to the same VPC can reach every other one. If that is too broad, firewall rules are what narrow it.

​
Troubleshooting

The instance is in a different location from your VPC. A VPC only accepts instances in the location it was created in — create one in the instance’s location.
Check the service is bound to the private address rather than to localhost, then check the firewall allows the traffic between them. ss -tlnp on the target answers the first question.
A newly attached instance may need its network reconfigured or a reboot before the interface appears. Confirm with ip -4 addr show.
Usually an overlap between the VPC range and another network the instance uses, most often Docker’s default bridge on 172.17.0.0/16. Compare with ip route.
The pattern worth adopting: application server with a public address, database on the VPC only. It removes an entire class of exposure, and it costs nothing beyond planning the addresses once.