> ## Documentation Index
> Fetch the complete documentation index at: https://www.datum.net/docs/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Agent home for Datum, with what it is, pricing, and how to act: https://agents.datum.net
> If you can only fetch URLs: read https://www.datum.net/docs/llms.txt in full and open the most specific page for the task. Commands, limits, and field paths are on task, operations, and limits pages, not on section overviews. Pages described as "Documentation is coming soon" are placeholders.
> If you have a shell or can save files: download https://www.datum.net/docs/llms-full.txt (every page, about 740 KB) once and search it with grep, instead of fetching pages one at a time.
> datumctl describes itself: `datumctl api-resources` lists resource types and `datumctl explain <resource>` shows a schema. To act on live resources, use Datum MCP or datumctl. To search the docs, use the Docs MCP server at https://www.datum.net/docs/mcp.

# Send paths to different origins

> Add routes to a Datum Application Load Balancer with datumctl, split traffic across several weighted origins, and understand what the cloud portal does with the result.

A load balancer starts with one route: everything on `/` goes to the origin you gave it. This guide adds more.

## Add a route

```bash theme={null}
datumctl alb route list my-app
datumctl alb route add my-app --path /api --endpoint https://api.example.com
```

Paths are prefix matches. `/api` catches `/api`, `/api/v1` and everything below it. The most specific match wins, so `/` keeps serving everything else.

To change where an existing route points:

```bash theme={null}
datumctl alb route update my-app --path /api --endpoint https://api-new.example.com
```

`route update` replaces every origin on that path and leaves the other routes alone. Preview anything you are unsure about first:

```bash theme={null}
datumctl alb route add my-app --path /api --endpoint https://api.example.com --dry-run
```

## Remove a route

```bash theme={null}
datumctl alb route remove my-app --path /api
```

The `/` route cannot be removed while other routes exist unless you pass `--force`, and the last remaining route cannot be removed at all.

> [!WARNING]
>
> `route remove` asks for confirmation when you run it in a terminal and **assumes yes when you do not** — in a pipeline or CI it proceeds. Use `--dry-run` first in automation.

## Several origins on one route

A route takes up to 16 origins, and requests are split across them by weight:

```bash theme={null}
datumctl alb route backend list my-app
datumctl alb route backend add my-app --path /api --endpoint https://api-2.example.com
datumctl alb route backend remove my-app --path /api --endpoint https://api.example.com
```

Removing the last origin on a route is refused. Remove the route instead.

Each URL origin is sent its own hostname as the Host header, so origins on different hostnames can share a route. A Host override on the route is the trap: it sends the same Host to every origin, so any origin that serves by hostname (Vercel, Netlify, Fly.io, Cloudflare Pages) answers the wrong site or a 404. It looks like it worked.

A connector origin has to be the only origin in its route.

### Weights

Weights are relative: origins at 1 and 3 get 25% and 75% of requests. An origin with no weight counts as 1. `route backend list` shows each origin's `WEIGHT` and `SHARE`.

```bash theme={null}
datumctl alb route backend add my-app --path /api --endpoint https://api-3.example.com --weight 2
datumctl alb route backend update my-app --path /api --endpoint https://api.example.com --weight 0
```

* Without `--weight`, `route backend add` gives the new origin the average weight of the pool, so adding one beside two origins at 50 gives it 50 rather than 1. A pool where no origin has a weight stays that way.
* `route backend update --weight 0` drains an origin: it stays in the pool and gets no requests.
* A change that would leave every origin on a route at weight 0 is refused, because the route would serve nothing.
* `route update` keeps the weight, TLS hostname and filters of any origin that stays in the new list.

The load balancing algorithm and passive health checks apply to every route. See [Load balancing and health checks](https://www.datum.net/docs/alb/configuration/load-balancing.md).

## Routes this plugin will not edit

`route list` marks some routes `advanced`. Those use path matches, header matches or filters beyond what the plugin represents — it leaves them alone rather than risk rewriting them. Edit those with `datumctl apply -f`.

Force HTTPS also appears in `route list`, marked `system`. It is a redirect rule with no origins behind it, and `route remove` will not delete it — use `datumctl alb update my-app --no-force-https`.

## What the cloud portal does with this

The portal manages one route: the pool of origins on `/`, with their weights, the load balancing algorithm and health checks. Those are the same fields `datumctl alb` writes, so you can change them from either.

The portal has no way to show a second route, a path match or a per-origin filter. When a load balancer has any of them, the portal makes its Backends tab and origin settings read-only, so it never drops what it cannot show. Custom hostnames, traffic protection and basic authentication stay editable there.

Manage a load balancer with more than one route with `datumctl alb`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.