Namespaces separate clients logically, but their pods still share nodes. A namespace is a logical partition inside one cluster.

When tenants must not share hardware, give each client its own **pool of nodes**. This puts isolation at the machine level, not just the namespace level. It is the pattern agencies and MSPs (managed service providers) use for clients that need a hard boundary.

## Why node-level isolation matters

Sensitive tenants, compliance rules, and noisy neighbors all need the same fix: separate machines. Short of a separate cluster, a dedicated pool is the strongest boundary, because a client's pods run only on that client's nodes.

## Two levers: dedicated machines and sandboxed workloads

Dedicating machines is one lever. The other is the runtime a workload runs under. The `secure` runtime class runs each pod inside its own lightweight virtual machine, so a container escape stops at the VM boundary. Together, the two levers let a sensitive tenant run sandboxed workloads on its own dedicated hardware. See [Run in the secure runtime](/docs/hetzner/apalla/workloads/secure/run-in-the-secure-runtime).

## One pool per client

Give each client a pool with a client label (see [Label nodes and assign roles](/docs/hetzner/apalla/servers-and-nodes/pools/label-nodes-and-assign-roles)):

```yaml
workers:
  machineDeployments:
    - class: workeramd64hcloud
      name: md-client-acme
      replicas: 3
      metadata:
        labels:
          node.cluster.x-k8s.io/client: acme
    - class: workeramd64hcloud
      name: md-client-globex
      replicas: 2
      metadata:
        labels:
          node.cluster.x-k8s.io/client: globex
```

## Steer each client's pods, and keep others off

Pin a client's workloads to its nodes with a `nodeSelector` or [node affinity](/docs/hetzner/apalla/servers-and-nodes/scheduling/node-affinity-and-selectors). A `nodeSelector` is a rule that keeps a pod on nodes carrying a given label:

```yaml
spec:
  nodeSelector:
    node.cluster.x-k8s.io/client: acme
```

A label attracts but does not repel. A pod without a `nodeSelector` can still land on a client's node. Syself Autopilot does not support node taints (see [Node taints are not supported](/docs/hetzner/apalla/servers-and-nodes/scheduling/apply-taints)), so the boundary is the pool label plus discipline on your side: give **every** workload a `nodeSelector`, so nothing lands on a client's pool by accident.

For a boundary that does not depend on every pod being labelled correctly, put sensitive tenants on their own **bare-metal** pool, where the hardware itself is the separation.

## Dedicated bare-metal pools for sensitive tenants

For a tenant that must be on physically separate hardware, not just a separate pod, give it a bare-metal pool. Bare-metal (Robot) servers are physical machines you own. A pool that only claims that tenant's hosts means no other tenant's pod can ever land on that hardware.

First label the tenant's `HetznerBareMetalHost` objects (see [Add bare-metal servers](/docs/hetzner/apalla/servers-and-nodes/provision/add-bare-metal-servers)):

```console
$ kubectl label hbmh baremetal-1 client=acme
```

Then point the pool at those hosts with `workerHostSelectorBareMetal`:

```yaml
- class: workeramd64baremetal
  name: md-client-acme-bm
  replicas: 2
  variables:
    overrides:
      - name: workerHostSelectorBareMetal
        value:
          matchLabels:
            client: acme
```

This is a second, separate label mechanism from the client pool label:

| Label                                             | Lives on                       | Decides                               |
| ------------------------------------------------- | ------------------------------ | ------------------------------------- |
| `client: acme` (host selector)                    | `HetznerBareMetalHost`         | Which physical machine joins the pool |
| `node.cluster.x-k8s.io/client: acme` (pool label) | `Node`, once the machine joins | Where pods land                       |

You need both: the host selector picks which hardware becomes Acme's, the pool label steers Acme's pods onto it.

> [!WARNING]
> Without a host selector, any free `HetznerBareMetalHost` can be claimed by any bare-metal pool in the same namespace, including ones a different client's pool is scaling into. Set `workerHostSelectorBareMetal` on every bare-metal pool, not only the sensitive one.

> [!NOTE]
> A per-client selector is the isolation you want, but it also leaves self-healing no other host to fall back to: if that tenant's server fails, the replacement re-claims the same machine, and a hardware fault survives the reinstall. Alert on the hardware [node conditions](/docs/hetzner/apalla/servers-and-nodes/access/node-problem-detection-and-conditions) so a broken server surfaces instead of quietly churning that client's pool. See [Self-healing does not repair hardware](/docs/hetzner/apalla/servers-and-nodes/maintenance/machine-health-checks-and-remediation#self-healing-does-not-repair-hardware).

You can run several bare-metal pools in one cluster, each selecting a different set of hosts, so each sensitive tenant gets its own machines. Check `kubectl get machines -o wide`: a bare-metal machine shows an `hrobot://` provider ID, confirming it landed on Robot hardware and not a cloud VM.

## Failure isolation per pool

For cloud pools, a Hetzner placement group keeps a pool's VMs on separate physical hosts. Without one, Hetzner can put two of a client's VMs on the same physical host, so one hardware failure takes both. `spread` is the only placement group type Hetzner Cloud supports.

Declare a group under `spec.topology.variables`, then reference it by name from the client's pool:

```yaml
variables:
  - name: hcloudPlacementGroups
    value:
      - name: acme-spread
        type: spread
workers:
  machineDeployments:
    - class: workeramd64hcloud
      name: md-client-acme
      replicas: 3
      variables:
        overrides:
          - name: workerMachinePlacementGroupNameHcloud
            value: acme-spread
```

Give each client pool its own group. Then one physical-host failure takes at most one node from one client, and a single failure never spans tenants.

See [Spread nodes with placement groups](/docs/hetzner/apalla/servers-and-nodes/provision/placement-groups) for how the groups are named and their limits.

Bare-metal pools do not need this. A Robot server already is one physical host, so the dedicated bare-metal pool above already gives you that isolation.

## Cost attribution and hand-off

Each client's capacity is its own pool of named machines, so you can work out the cost per client from the machine type and count in that pool, and scale each pool on its own.

Keeping clusters on the customer's own Hetzner account makes the hand-off clean. The machines, and their bill, already sit with the customer.

<Collapsible title="Isolate the client's network traffic and cluster access too">

A dedicated pool isolates compute: which machine a client's pods run on. It does not stop a client's pods from talking to another client's pods over the network. It does not stop a client's team from viewing another client's namespace either.

Add these two layers along the same client boundary when the tenant needs them:

- **Network policy.** Put each client in its own namespace and add a [`NetworkPolicy`](/docs/hetzner/apalla/security/segment-with-network-policies) that blocks cross-namespace traffic. Pod-to-pod traffic is allowed by default until you write one.
- **RBAC.** Give the client's own team access to only their namespace with an `AccessTemplate` and `ClusterPermission`, instead of a shared kubeconfig. See [Manage access and tenancy](/docs/hetzner/apalla/security/manage-access-and-tenancy).

Node pool, namespace network policy, and RBAC together isolate compute, traffic, and access along the same client boundary.

</Collapsible>

## Where to go next

- [Label nodes and assign roles](/docs/hetzner/apalla/servers-and-nodes/pools/label-nodes-and-assign-roles)
- [Mix cloud and bare-metal pools](/docs/hetzner/apalla/servers-and-nodes/pools/mix-cloud-and-bare-metal)
- [Size a cluster for cost](/docs/hetzner/apalla/servers-and-nodes/fleet/size-a-cluster-for-cost)
- [Agencies and MSPs](/docs/hetzner/apalla/security/multi-tenant-isolation-for-agencies)