> ## Documentation Index > Fetch the complete documentation index at: https://datum.net/docs/llms.txt > Use this file to discover all available pages before exploring further. # Serve public traffic with ALB > Attach Datum's Application Load Balancer (ALB) to a workload to serve public HTTP and HTTPS traffic, and add your own domain. Instances have private IPv6 addresses only, so the internet can't reach them directly. `--http-port` is the quickest way to attach an ALB to a workload: it declares the port your container serves HTTP on and creates an `HTTPProxy` for the workload. Datum terminates TLS at the ALB, sends each request to the nearest location with a healthy Instance, and connects to your Instances over plain HTTP on your private network. > [!NOTE] > > Compute is in preview, and the `v1alpha` API can change. ## Before you begin * Select a project, install the `compute` plugin, and get access to Compute. For more information, see [Compute commands](https://datum.net/docs/datumctl/compute/overview.md). * Make sure that you have permission to create networking resources in the project, in addition to compute resources. The **Network Admin** role includes the permissions that publishing needs. The **Gateway Admin** role alone isn't enough. * Make sure that your app serves plain HTTP, not HTTPS, on the port that you publish, and listens on IPv6. ## Attach an ALB with datumctl To attach an ALB to a workload, run `datumctl compute deploy` with `--http-port`: ```bash theme={null} datumctl compute deploy WORKLOAD_NAME \ --image=IMAGE \ --location=LOCATION \ --http-port=PORT ``` Replace the following: * `WORKLOAD_NAME`: the name of your workload. * `IMAGE`: the full image reference, including the registry host. * `LOCATION`: one or more locations, separated by commas. * `PORT`: the port that your container serves HTTP on, such as `8080`. `--http-port` works when you create a workload and when you update one that you deployed with flags. > [!WARNING] > > A flag-based `datumctl compute deploy` replaces the workload's whole template and placements with what the flags describe. It keeps environment variables, ConfigMap and Secret imports, volumes, and labels. It removes registry credentials, custom commands, and extra placements that you set in a manifest, and it sets the Instance count to the `--min` value, which defaults to `1`. To publish a workload that you manage with a manifest, see [Publish a workload you manage with manifests](#publish-a-workload-you-manage-with-manifests). The command declares the port on the container, waits for the rollout, and then prints the publishing progress and the ALB's hostname as the last line of output: ```text theme={null} Publishing... Backends 2 healthy across us-central-1, us-east-1 Edge programmed Certificate issued https://stark-raven-b7k2m.datumproxy.net ``` Your hostname is different. A new hostname can take a few minutes to resolve. If a request fails with a name resolution error, wait and try again. If you press Control+C while the command publishes, publishing continues in the background. If your app speaks HTTP/2, such as a gRPC server, also add `--http2` to the command, and serve HTTP/2 without TLS (h2c) on `PORT`. Without the flag, Datum connects to your Instances over HTTP/1.1, which most apps expect. gRPC needs HTTP/2 on every connection, so with the flag, Datum connects to your Instances over HTTP/2 too. Clients connect to the ALB hostname on port 443, such as `grpcurl stark-raven-b7k2m.datumproxy.net:443 list`. Later deploys keep the setting, and `--http2=false` turns it off. ## Find your workload's ALB hostname To see the ALB hostname of every workload in your project, run the following command: ```bash theme={null} datumctl compute workloads ``` The hostname is in the `URL` column. To see the hostname and the health of the Instances behind it in each location, run the following command: ```bash theme={null} datumctl compute workloads describe WORKLOAD_NAME ``` In the [Cloud Portal](https://cloud.datum.net), a workload's **Overview** tab shows its hostname, and a topology of the ALB in front of the workload and its Instances in each location, with live traffic, error rate, and latency. ![A workload Overview tab showing Serving normally, and a topology diagram linking the load balancer, with traffic, errors, p99 latency, and hostname, to the workload, with 6 of 6 Instances ready across 3 locations](https://mintcdn.com/datum-4926dda5/Xc9AnQUL-oEENeSS/images/compute-workload-topology.png?fit=max\&auto=format\&n=Xc9AnQUL-oEENeSS\&q=85\&s=ebaca5e2ce09e908280ba29698a8cb57) A published workload: its ALB, the workload, and its Instances in each location If you have `jq` installed, you can read the hostname in a script. Run the following command: ```bash theme={null} datumctl compute workloads -o json | jq -r '.[] | select(.name=="WORKLOAD_NAME") | .url' ``` Replace `WORKLOAD_NAME` with the name of your workload. ## Change or remove the ALB The ALB keeps its hostname when you redeploy the workload. If you run `datumctl compute deploy` without `--http-port`, the workload keeps its current port and the ALB keeps its hostname. To change or remove the ALB, do one of the following: * To serve on a different port, run `datumctl compute deploy` again with the new `--http-port` value. The hostname stays the same. * To stop serving the workload publicly, run `datumctl compute deploy` with `--no-http`. This removes the ALB, and the hostname stops responding. Datum generates the hostname when it creates the ALB. If you remove the ALB and publish again, the workload gets a new hostname. `datumctl compute destroy` removes the workload's ALB along with the workload and its Instances. A plain `datumctl delete workload` deletes the workload and its Instances, but leaves the ALB in place. For more information, see [Delete a workload](https://datum.net/docs/compute/operations#delete-a-workload). ## Use a custom domain You can serve a published workload on your own domain, such as `api.example.com`, in addition to its generated hostname. The ALB is an `HTTPProxy` resource named after the workload. For more on custom hostnames, TLS, and WAF protection, see [ALB](https://datum.net/docs/alb/overview.md). To add a custom domain, follow these steps: 1. Add and verify your domain in Datum. For more information, see [Domains](https://datum.net/docs/domain-dns/domains.md). 2. To open the workload's `HTTPProxy` for editing, run the following command: ```bash theme={null} datumctl edit httpproxy WORKLOAD_NAME ``` Replace `WORKLOAD_NAME` with the name of your workload. 3. Add your hostname to `spec.hostnames`, and then save and close the file: ```yaml theme={null} spec: hostnames: - api.example.com ``` 4. Point your hostname at the workload's generated hostname with a `CNAME` record. If Datum hosts your DNS, see [Point a domain at a load balancer](https://datum.net/docs/domain-dns/point-to-alb.md). `datumctl compute deploy` keeps custom hostnames when it updates a workload. `datumctl compute destroy` removes the ALB, including its custom hostnames, but keeps your domain resources. ## Publish a workload you manage with manifests A workload manifest can't declare an ALB, and `datumctl compute deploy -f` doesn't create or remove one. To attach an ALB to a manifest-managed workload, follow these steps: 1. Create the workload with `datumctl compute deploy` and `--http-port`, as described in [Attach an ALB with datumctl](#attach-an-alb-with-datumctl). The command saves the workload to `workload.yaml` in the current directory. 2. Rename `workload.yaml`, and make your changes in the renamed file. Keep the container port that you published. 3. To apply later changes, run `datumctl compute deploy -f FILE`, where `FILE` is the path to your manifest. The workload keeps its ALB. ## Limitations In addition to the [limitations that apply to all of Compute](https://datum.net/docs/compute/limitations-and-roadmap.md), the ALB has the following limitations: * Clients always connect over HTTPS. Datum connects to your Instances over plain HTTP, and TLS between Datum and your Instances isn't supported. * `datumctl compute deploy` attaches one ALB to each workload, on one port. * With `--http2`, WebSocket connections also reach your Instances over HTTP/2, and most servers accept WebSockets only over HTTP/1.1. To serve WebSockets alongside gRPC, serve them on a separate port through a [network service](https://datum.net/docs/galactic-vpc/networks/network-services.md). ## What's next * To run in more locations so that more users reach a nearby Instance, see [Placement and scaling](https://datum.net/docs/compute/placement-and-scaling.md). * To learn more about `HTTPProxy` routing and options, see [Application Load Balancer](https://datum.net/docs/alb/overview.md). * To learn how Instances connect privately, see [Traffic and connecting](https://datum.net/docs/galactic-vpc/networks/traffic.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.