---
title: "Load balancers"
description: "Regional TCP load balancers on Metalhost: one public IPv4 in front of several VMs, TCP health checks, connection draining, and the client"
url: "https://metalhost.com/docs/dashboard/guides/load-balancers"
---

# Load balancers

A load balancer puts one public IPv4 in front of several VMs in a private subnet. It balances TCP connections across healthy backends, and TCP health checks take unhealthy ones out of rotation.

## What it does

- **TCP (layer 4)** — TLS passes through untouched, so your VMs keep their certificates. HTTP termination, UDP, and PROXY protocol aren't supported.
- **Real client IPs** — backends see the client's actual source address at the network layer, with no PROXY protocol or headers needed.
- **Regional** — a load balancer, its address, and its backends are in one region and one private subnet.
- **Its own address** — each load balancer gets a public IPv4 of its own, shown on its card. It's separate from your [reserved public IPs](https://metalhost.com/docs/dashboard/guides/public-ipv4.md).

> **self-hairpin exception**
>
> When a backend VM connects to its own load balancer's address, that connection may arrive from a Metalhost platform address instead of the VM's own. Traffic from external clients always keeps its source IP.

## Create a load balancer

**Networking → load balancers → Create load balancer**.

1. **Name** it and pick the **Private subnet** — this fixes the region and VPC, and can't be changed later.
2. Add **TCP listeners** (1–64): each maps a public port to a backend port, for example `443 → 8443`. Public ports must be unique.
3. Choose the **backends**: VMs in that subnet.
4. Optionally tune health checks and the connection drain timeout, then create.

## Health checks

Each listener checks its backends with TCP connections — by default on the backend port, or on a separate **health-check port**.

| Setting | Meaning |
| --- | --- |
| Check interval (seconds) | How often each backend is checked. |
| Timeout (milliseconds) | How long a check waits. Must be shorter than the interval. |
| Failures to become unhealthy | Consecutive failed checks before a backend is taken out. |
| Successes to become healthy | Consecutive passing checks before it's put back. |

Traffic only goes to healthy backends. If none are healthy, new connections fail rather than reaching a backend known to be down. Each load balancer shows per-backend health, and a VM's networking tab lists the load balancers it serves with *this vm's health*.

## Connection draining

When you remove a backend or delete the load balancer, existing connections are kept for the **connection drain timeout** before being closed. New connections go to the remaining backends.

## Change or delete

Open a load balancer to edit its name, listeners, backends, and health checks. **Delete load balancer** stops new connections, drains existing ones, and returns its public IPv4.

## What's next

- [VPCs & subnets](https://metalhost.com/docs/dashboard/guides/networks.md) — where backends live.
- [Firewall rules](https://metalhost.com/docs/dashboard/guides/firewall.md) — inbound policy on each VM.
- [Public IPs](https://metalhost.com/docs/dashboard/guides/public-ipv4.md) — dedicated addresses for single VMs.