Private Networking

Bahriya keeps your projects isolated from one another by default and lets you open only the specific connections your workloads need. This article explains the private-by-default model and how network policies build on it.

Updated 3 Aug 20263 min read

Private by default

Every project runs in its own isolated network space. Workloads in one project cannot reach workloads in another — even within the same organisation — and nothing outside a project can reach in unless you explicitly allow it. Within a project, containers can talk to each other and to Memcached over the internal network.

You do not need to configure anything to get this isolation. It is the baseline every project starts from.

Opening specific connections

When a workload genuinely needs to reach across that boundary — or you want to constrain what it can reach on the outside — you attach a network policy. A policy is a set of allow rules layered on top of the private baseline. You describe the connections that should be permitted, and everything else stays closed. Rules only ever add access; a policy can never widen access you did not write down.

A policy can cover three things:

Rule	Controls
Ingress peers	Which other projects in your organisation may reach the workloads this policy protects
Egress IP ranges	The outbound IP ranges your workloads may send traffic to
Egress domains	The domains your workloads may reach

Optional port and protocol scoping narrows any of these further.

Note

Adding any egress rule switches outbound traffic to deny-by-default: only the ranges and domains you list get through. A policy with no egress rules leaves outbound traffic open and only constrains who may reach in.

Restricting egress

By default a workload can make outbound connections freely. If you want to limit where it can send traffic — to keep a compromised dependency from calling home, or to satisfy an internal policy that outbound traffic go only to approved destinations — add egress rules.

Prefer egress domains over IP ranges when allowing traffic to a third-party service. A service's IP addresses can change without notice; the domain does not. Reserve IP-range rules for destinations you control or that publish stable ranges.

Scoping a policy to the right workloads

You choose the scope when you attach the policy:

Whole project — applies to every container and datastore in the project, including ones deployed later. Use this for guardrails that should always hold.
A single container — gives just that workload its own ingress peers or outbound allowances, without touching the rest of the project.
A datastore — controls exactly which workloads may connect to a managed datastore.

A policy attached to the whole project already covers every workload in it, so there is no need to also attach it to individual containers.

A worked example

Suppose a frontend project needs to call an API in a backend project, and the API must reach a payment provider but nothing else outbound:

On backend, allow ingress from the frontend project.
On backend, add an egress domain rule for the payment provider's API domain. Because this is the first egress rule, outbound traffic becomes deny-by-default and only that domain gets through.

Everything else — other projects reaching in, other outbound destinations — stays closed.