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

​
Add a route

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:
route update replaces every origin on that path and leaves the other routes alone. Preview anything you are unsure about first:

​
Remove a route

The / route cannot be removed while other routes exist unless you pass --force, and the last remaining route cannot be removed at all.
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 traffic is split across them:
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.
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.
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.
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: 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.
Last modified on September 26, 2026