Skip to main content
A private network link between your network and the Galtea platform, so that neither side has to expose anything to the public internet. Use it in either direction:
  • Galtea reaches your AI product. Your endpoint stays private, reachable only inside your own network, and there is no public URL and no source address to allowlist.
  • Your team reaches the platform. The dashboard and API stay internal, with no public ingress.
Connectivity implementation covers the alternative, which is a public endpoint with an egress allowlist, and when each is the better answer.

​
What it is

A WireGuard mesh. WireGuard is the encryption and tunnelling protocol built into the Linux kernel; the mesh on top of it is NetBird, which Galtea self-hosts rather than consuming as a service. Self-hosting matters here: the control plane runs inside the Galtea infrastructure for your deployment, so no third-party SaaS sits in the path of your credentials or your traffic. Two planes, and the distinction decides your firewall rules: The control plane never carries application traffic. It hands out keys and policy. Peers then talk to each other directly.

​
The endpoints you connect to

Both are per deployment, with <tenant> replaced by your deployment’s name, which Galtea gives you: What you open on your side: If no direct path can be established, and a strict NAT or a symmetric gateway on either side is enough to prevent one, the tunnel falls back to the relay over TLS 443. The relay forwards packets it cannot decrypt, so the fallback costs latency, never confidentiality.

​
Three ways to connect

Pick by what you need to reach, not by preference. They combine. A routing peer for your cloud network and a client on two engineers’ laptops is a normal setup, and each peer is authorized separately. You install and run the peers. Galtea operates the control plane. That split is the same in all three, and it means you need no account, no console and no administrative access to the mesh itself: So every step below that needs a change in the control plane is a request to Galtea, which makes it. Galtea agrees the routes and groups with you before anything is enabled, and holds them in configuration rather than clicking them in, so what is reachable can be reviewed at any time. All three are standard NetBird client-side setups: Galtea operates and validates the management, signal and relay services, and each mode follows NetBird’s own documentation in your environment. Galtea works with your team on the client-side setup for whichever mode you choose.

​
Host to host

One machine joins the mesh and gets an address on it. Nothing else in your network becomes reachable, and nothing else needs to change. Pick it when a named machine is the endpoint: a jump host your engineers use, or a single server that hosts the AI product you want evaluated. How it is done:
  1. Install the client. There are packages for Linux, macOS and Windows, and a Docker image. See Installation.
  2. Join the mesh, pointing it at your management address instead of the hosted service.
  3. A browser opens for you to sign in. On a machine with no browser, use a setup key instead, as in Authentication and enrolment below.
  4. Confirm it worked. netbird status lists the peers you can reach and whether each path is direct or relayed.
Day to day the client runs as a service and reconnects on its own. netbird down leaves the mesh without uninstalling anything. The full command set is in the CLI reference.

​
Routing peer on a node in your cloud network

One virtual machine inside your own virtual network joins the mesh and advertises routes to subnets behind it. Traffic to those subnets flows through it, so the machines behind it need no client installed and no change at all. Pick it when the platform must reach several services, or something that cannot run a client, such as a managed database or an appliance. This is the usual answer for a cloud network, and the least intrusive: one VM, and no change to any workload. How it is done:
  1. Create a small virtual machine in the network you want reachable. It forwards packets rather than running workloads, so the smallest instance type is normally enough.
  2. Enable IP forwarding on it, at the operating system level and, on most clouds, on the network interface as well. A cloud that drops traffic whose destination is not the instance itself will silently break the route otherwise.
  3. Install the client and join the mesh with a setup key, so the peer needs no interactive login and survives a reboot without a person.
  4. Galtea declares the route, in the control plane. Tell Galtea: That last one decides one setting. By default the routing peer replaces the source address of forwarded traffic, which needs no configuration on your side. Preserving the original address is possible and then your network needs a return route back to the mesh, so it is worth saying up front rather than discovering it during a test.
  5. Check from the other side that the destination answers, rather than that the peer is connected. A connected peer with a route not yet in place looks identical to a working one until traffic flows.
For a path that survives losing the VM, run a second one the same way and tell Galtea: both then advertise the same range and traffic follows whichever is available. Nothing changes on the machines behind them. What the routes and groups mean, and the settings Galtea configures on your behalf, are described in Routing traffic to private networks.

​
Kubernetes

The NetBird operator runs in your cluster and exposes selected Kubernetes services to the mesh, resolvable by name, without giving the mesh access to the rest of the cluster. Pick it when the thing to reach is a service in Kubernetes and you would rather declare that in your cluster, next to the service, than maintain a VM. How it is done:
  1. Install the operator with Helm, from the NetBird project’s own registry:
  2. Store the credential Galtea issues you for the management API. The operator reads a token from a Kubernetes secret named netbird-mgmt-api-key, and its pod does not start without it. The token is scoped to your deployment and Galtea revokes and reissues it on request.
  3. Declare what to expose, in your own cluster. The operator adds custom resources; a NetworkRouter makes selected ClusterIP services reachable from the mesh, named service.namespace.<zone> in a DNS zone the operator manages. Nothing else in the cluster becomes reachable. This is the one mode where you declare what is exposed rather than asking Galtea, which is the reason to pick it.
  4. Resolve that name from a connected peer to confirm it, not just the operator’s own logs.
The trade-off against a routing peer on a VM: this is declarative and lives with the service, and it needs permission to install cluster-scoped custom resource definitions plus a stored API token. Details are in the Kubernetes operator guide.

​
Authentication and enrolment

Two ways a peer joins, for two different situations: The interactive login uses the OAuth Authorization Code flow with PKCE, the standard browser flow, so no long-lived credential is stored on the machine. If your organization uses its own identity provider, it can be federated into the Galtea one over SAML or OpenID Connect, which means your directory stays the source of truth: removing a person there removes their access to the mesh, with no separate offboarding step. Setup keys are for machines rather than people, and Galtea issues them, one per purpose. A peer enrols with one command, with no browser and no person:
The key Galtea gives you already carries the group that decides what the peer may reach, so enrolling is the last step on your side: there is nothing to configure afterwards. Each key can be single-use or reusable, and revoking one does not affect any other peer. Background in Register machines using setup keys.

​
What is reachable, and what is not

Only the routes a peer advertises, and only for the peers your policy allows.
  • The dashboard and the API, yes, when that is what you asked for.
  • Databases, internal services and everything else in the same network, no, even for a connected peer, unless a route for them was advertised deliberately.
Access is granted per group rather than per peer, so adding a machine to a group is what grants it a path and removing it is what revokes one. Ask Galtea for either and it takes effect without reinstalling or reconfiguring anything on the peer. The rule model is described in Manage network access.

​
Where to read more

Two things to keep in mind while reading them. Point the client at your own management address rather than the hosted service, and treat the pages about routes, groups and access rules as background: they describe the control plane, which Galtea operates for you, so the steps there are what Galtea does rather than what you do.