Suppose a catalog API and its database are deployed as separate applications. The API needs a private SQL connection, while the storefront should have no database access.
Hakopod virtual networks let you grant access to selected applications, connect individual services, and restrict which peers can reach each port. This example walks through that setup.
Separate the grant from the connection
A Hakopod virtual network belongs to one project and environment. It contains named segments, and each segment grants access to named applications. A grant permits an application to join; it does not attach every service in that application.
For example, this is a complete virtual-network definition for two sets of connections:
schema_version = 1
name = "commerce"
description = "Storefront and data connections"
[segments.frontend]
applications = ["storefront", "catalog"]
[segments.data]
applications = ["catalog", "database"]The storefront can be granted the frontend segment without being granted the data segment. The catalog application can connect the particular services that need one or both.
Development and production can use the same network name without becoming the same network. The project and environment are part of its scope. Cross-environment peer references are rejected.
Attach the service, then restrict its peers
In the database application’s existing TOML, a local network can point to the shared segment:
[networks.data]
internal = true
virtual_network = "commerce"
segment = "data"Attach the database service to that local network, declare its private SQL port, and restrict its incoming peers. For an existing service named postgres, the peer-rule excerpt is:
[services.postgres.network_access]
from = []
from_applications = ["catalog/api"]These are excerpts, not a complete database deployment. Start from the PostgreSQL template for its password binding, storage and resource configuration. The catalog/api service must also join the shared data segment, and both source egress and destination ingress must permit the connection.
An explicit empty from list denies same-application peers. The from_applications list names an exact application and service rather than everyone who happens to share a project. If you leave out the whole network_access block, declared ports accept connections from members of the service’s networks.
Check the path you actually created
The network inspector shows configured membership, private DNS names, ports and application revisions. Copy its address instead of guessing a hostname. Check the deployment status too: a saved connection is not proof that reconciliation has finished.
If a connection fails, inspect four things in order: the application’s grant, the service’s membership, its peer rules, and the advertised port versus the container target port. The two port numbers may intentionally differ.
Review network changes before applying them. Detach a service and successfully deploy the change before removing its grant. A rollback to an old connection still needs today’s grant; deployment history is not permission to bypass a later access decision.
Know what the boundary provides
These networks use Kubernetes NetworkPolicy and require a compatible networking plugin, called a CNI, that enforces those policies. They do not create a VPC, allocate subnet CIDRs, encrypt traffic or connect separate clusters. Broader policies installed by a cluster administrator can also allow additional traffic because Kubernetes policies are additive.
Those limits matter when choosing the right tool. This model gives an operator a practical way to describe private application connections. Unrelated hostile tenants require a wider isolation design than service membership alone.
The networking guide covers local networks, shared segments, private ports and the separate rules for public exposure.