> ## Documentation Index
> Fetch the complete documentation index at: https://datum-4926dda5-docs-alb-skill-product-model.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Send paths to different origins

> Add routes to a Datum Application Load Balancer with datumctl, split traffic across several 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.
</Warning>

## Several origins on one route

A route takes up to 16 origins, and traffic is split across them:

```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.

### The one rule that decides whether a pool works

**Every origin in a route must agree on the Host header sent upstream.**

* Origins that are **network services** need no Host rewrite, so pools of those work.
* A **URL origin** takes its Host from its own hostname, so two URL origins on different hostnames conflict.

<Warning>
  When they conflict, the command still succeeds. The conflict is caught when the platform tries to publish the change, not when you make it, so you get an exit code of zero and a success line — and the load balancer goes on serving what it published last. Run `datumctl alb describe my-app` after adding a second URL origin; it will show `Error` with the conflict in the message.
</Warning>

There are two ways round it, and one is a trap:

**Give each origin its own route.** Safe, and usually what you actually wanted.

**Set a Host override on the route.** This makes the origins agree and it publishes — but every origin then receives the same Host. Any origin that serves by hostname (Vercel, Netlify, Fly.io, Cloudflare Pages) will answer the wrong site or a 404. It looks like it worked, which is what makes it worse than the error.

```bash theme={null}
datumctl alb header set my-app Host=origin.example.com
```

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

## 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

This is the part worth reading before you add a route.

The portal edits **one route with one origin**. It has no way to show a second route, a second origin, or a path match, and it does not tell you they are there.

It does not stop you editing, either. Changing the origin, TLS settings, Force HTTPS or the Host header in the portal rebuilds the whole route list from the few fields it models — so anything beyond its shape is dropped, and the save reports success.

So once a load balancer has routes or a pool:

| In the portal                         | Safe?                         |
| ------------------------------------- | ----------------------------- |
| Custom hostnames                      | Yes — does not touch routes   |
| Traffic protection                    | Yes                           |
| Basic authentication                  | Yes                           |
| Origin, TLS, Force HTTPS, Host header | **No — discards your routes** |

Manage a multi-route load balancer with `datumctl alb`, and keep portal edits to hostnames, protection and auth until the portal's own routes editor ships.