Private networks (VPC)

Updated 2026-10-30

A Wolkra private network is your own isolated network in Frankfurt that links servers with private addresses from IP ranges you choose, so they can talk to each other without exposing anything to the internet. Servers can even live on a private network with no public IP at all.

Why use a private network

Most stacks have parts that should never face the internet: databases, caches, queues, internal APIs, admin tools. A private network, also called a VPC (virtual private cloud), gives those parts a place to live.

• Less exposure: a database with no public address cannot be scanned or attacked from outside.
• Simple addressing: services find each other on stable private addresses that you control.
• Clean architecture: public traffic arrives at a load balancer or one gateway server, everything else stays inside.

What you can do

• Create networks with your own IP ranges and split them into subnets
• Attach servers when you create them or later, with one or more network interfaces
• Run private-only servers without a public IPv4 or IPv6
• Give private servers internet access through a NAT gateway for updates and outbound API calls
• Publish a private server with an Elastic IP, a public IP NATed to it
• Put load balancers in front of private servers, so only the balancer has a public address
• Combine with firewalls for rules on both the public and private side

How it works in the console

1. Open Networks and create a network. Choose a name and an IP range.
2. Add one or more subnets inside that range.
3. When you create a server, select the network. You can also untick public IPv4 and IPv6 to make the server private-only.
4. Existing servers can be attached to a network from the server page.
5. Add a NAT gateway if private servers need outbound internet access.

The private networks doc walks through a full setup with a web server, a database and a NAT gateway.

Using the API

Networks, subnets and server attachments are all available through the Wolkra API. That makes it easy to create a fresh, isolated environment per branch, per customer or per test run, and delete it when you are done.

You can also draw networks visually in Composer, connect servers to them on the canvas and see the monthly cost before anything is created.

A typical layout

Visitors reach the load balancer. The load balancer forwards to app servers over the private network. App servers talk to the database privately and reach the internet for updates through the NAT gateway. Nothing except the balancer and the gateway can be reached from outside.

Typical uses

• Web apps with a separate database tier, see web hosting
• Databases that should never be public
• Multi-server SaaS backends
• Internal services next to a WireGuard VPN for admin access
• Build farms of CI runners that only need outbound access

Planning your IP ranges

Pick a range that will not clash with networks you already use, such as an office network or a VPN you connect over. Leave room to grow: it is easier to start with a larger range and add subnets than to renumber later. Many teams give each environment its own network, for example one for production and one for staging, so a mistake in one cannot reach the other.

Limits to know

• Networks connect servers in the same location. Today that is Frankfurt.
• A private-only server needs a NAT gateway for outbound internet access.
• Prices for networks, NAT gateways and Elastic IPs are on the pricing page.

Related products

• NAT gateways for outbound access
• IP addresses, including Elastic IPs
• Load balancers and firewalls
• Network for unmetered bandwidth and IPv6

Build a private network

Keep your databases and internal services off the internet from the start. Sign up for Wolkra and create your first VPC in Frankfurt.