Overview
Haribon is an HTTP load balancer. It accepts requests on a port you choose and forwards each one to a backend server it picks from a list you write in a YAML file. It is one binary with one dependency — a YAML parser — and no runtime to install alongside it.
It is deliberately narrow. It does not terminate TLS, inspect paths or hostnames, rate-limit, or trace requests. Every request goes to the backend pool. If you need those things, put Haribon behind something that provides them, or reach for a different tool.
When to Use Haribon
Microservices in development
Point it at several local instances of a service and get a single address for all of them. Health checks mean a crashed instance stops receiving traffic while you are still debugging it, instead of feeding you connection errors.
Small to medium production services
When you need requests spread across a handful of servers, health checks, and a metrics endpoint, without taking on the configuration surface of a full ingress controller. The whole config file is one screen long.
Backends that come and go
If a deploy script, an orchestrator, or a DNS record already knows which servers exist, Haribon can follow it — from a JSON file or from DNS — and pick up additions and removals without a restart.
Fronting services that cannot look after themselves
Legacy services that have no health endpoint of their own still get taken out of rotation when they stop answering, because Haribon probes them from the outside. No changes to the service required.
Key Benefits
- One binary, one dependency — nothing to install beside it, and no library you have to keep patched
- Failing servers are skipped, not served — background probes take a bad backend out of rotation and put it back when it recovers
- Retries where they are safe — connection failures are retried on another backend, but never for a method that would repeat a side effect
- The server list can change while it runs — from DNS, from a file another system rewrites, or by reloading the config
- More than one of them, if you want — replicas share what they find about each backend over UDP; no coordination service, no leader
- You can see what it did — Prometheus metrics, one log line per request, and optional shipping to Loki, Elasticsearch, or Fluent Bit
How It Works
Haribon listens on a host and port, accepts an HTTP request, and asks the configured strategy which backend should get it. Round-robin is the default; you can also weight the servers, send to whichever has the fewest connections in flight, choose at random, or hash the visitor's address so they keep landing on the same server.
Before it forwards anything, it checks whether the backend it picked is currently considered healthy. A backend that has failed enough probes — or enough real requests, if the circuit breaker has opened — is skipped in favour of the next candidate. That is what makes a server going down a non-event rather than an outage.
Each request is logged as one line, and the counters behind /metrics are updated as it completes. Both are cheap because there is no agent involved: the same process that proxied the request is the one that recorded it.