A Hetzner load balancer serves bare-metal (Robot) nodes exactly like Cloud nodes. The CCM handles both natively, so there is nothing extra to do for bare metal. Point a `type: LoadBalancer` Service at a pool that includes Robot servers and it works. The rest of this page explains how the CCM adds each kind and how the standard settings behave, so a mixed pool is easy to reason about.

## Server targets and IP targets

The CCM adds the two machine kinds as different target types:

- **Hetzner Cloud nodes join as server targets.** The CCM references the cloud server by its ID, and Hetzner tracks it.
- **Bare-metal (Robot) nodes join as IP targets.** The CCM adds the Robot server by its public IPv4 address.

Both back the same `type: LoadBalancer` Service, so a mixed pool of Cloud and Robot nodes works, and the load balancer spreads traffic across both.

## Bare-metal targets stay IPv4

By default the platform pins bare-metal targets to IPv4, with `HCLOUD_LOAD_BALANCERS_ROBOT_TARGET_ADDRESS_FAMILY=ipv4` on the CCM. This is the same reason the rest of the cluster runs IPv4: nodes have no usable IPv6, so an IPv6 target would never pass its health check and would remain permanently unhealthy. On an IPv4-only cluster the default is the correct setting, and you leave it unchanged.

You can set the family per Service with the `robot-target-address-family` annotation:

```yaml
metadata:
  annotations:
    load-balancer.hetzner.cloud/robot-target-address-family: ipv4
```

## Traffic policies on bare-metal servers

Service traffic policies behave identically on bare-metal and cloud nodes. For deep dives on how `externalTrafficPolicy` impacts packet hops and source IP preservation, see [Preserve the client source IP](/docs/hetzner/apalla/network/load-balancing/preserve-client-source-ip).

When configuring `externalTrafficPolicy: Local` on bare-metal nodes:

- **Schedule pods on all target servers:** The load balancer will only route traffic to bare-metal servers running a ready replica. Ensure your pods are evenly distributed (or deployed via a DaemonSet) so physical servers do not sit idle.
- **Tune health checks:** See [Tune health checks for node replacement](/docs/hetzner/apalla/network/load-balancing/health-checks-and-node-replacement) to ensure fast target pool ejection during maintenance.

For why you would run bare metal at all, and how to add it, see [Bare metal, cloud, and accelerators](/docs/hetzner/apalla/concepts/internals/bare-metal-and-cloud) and [Add bare-metal servers](/docs/hetzner/apalla/servers-and-nodes/provision/add-bare-metal-servers).