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

# ALB limitations and roadmap

> Review what the Datum Application Load Balancer doesn't support or document yet, and where to follow what comes next.

The Application Load Balancer is still being built. This page lists known limitations and where to follow what comes next.

## Limitations

* There is no single composite ALB API yet. An ALB is an `HTTPProxy`, a `TrafficProtectionPolicy`, and optional authentication resources. See [What an ALB is made of](https://www.datum.net/docs/alb/overview.md#what-an-alb-is-made-of).
* Public traffic is HTTP and HTTPS only. Raw TCP and UDP exposure isn't available.
* Rule exclusions, score thresholds, rate limiting, and circuit breaking aren't available through `datumctl alb`. Use manifests. See [Web application firewall](https://www.datum.net/docs/alb/configuration/waf.md).
* A `connector` backend must be the only backend in its rule.
* You can't choose which Datum locations serve a load balancer or set its capacity. [Envoy](https://www.datum.net/docs/platform/envoy.md) in every location serves every load balancer, and Datum scales the fleet.
* Envoy connects to Compute Instances over plain HTTP. TLS ends at the load balancer.
* Status shows when a change is published, not when every location serves it, and there is no per-location status. See [When a load balancer is not serving](https://www.datum.net/docs/alb/troubleshooting.md).
* Request timeouts aren't documented yet, including how long a streaming response can stay open: Server-Sent Events (SSE), WebSockets, or a long MCP response. `HTTPProxy` has no timeout setting, so test long-lived responses before you rely on them.
* The headers that Datum adds to requests it forwards to your origin, such as the client's IP address (`X-Forwarded-For`) and the original protocol (`X-Forwarded-Proto`), aren't documented yet.
* `ClientTrafficPolicy` isn't available in projects, so client-side TLS versions, HTTP versions, and connection limits can't be changed.
* For limits on load balancers attached to Compute workloads, see [Compute and ALB](https://www.datum.net/docs/compute/compute-and-alb.md#limitations).

## Roadmap

For what Datum is building next across the platform, see the [Platform roadmap](https://www.datum.net/docs/platform/roadmap.md).

> [!NOTE]
>
> Plans can change. This list isn't a commitment to deliver any feature or to meet any timeline.


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