> ## 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. # ALB operations > Create, inspect, update, and delete Application Load Balancers with the datumctl alb plugin. To install the `datumctl alb` plugin, run `datumctl plugin install alb`. ## Create a load balancer To create a load balancer in front of an origin, run the following command: ```bash theme={null} datumctl alb create ALB_NAME --endpoint ORIGIN_URL ``` Replace the following: * `ALB_NAME`: a name for the load balancer, such as `my-app`. * `ORIGIN_URL`: the `http` or `https` URL of your origin, such as `https://origin.example.com`. The command waits up to 2 minutes for Datum to assign a generated hostname, then prints it: ```text theme={null} Application load balancer "my-app" created. Hostname: piece-build-byrkx.datumproxy.net ``` Point your custom domains at this hostname with a `CNAME` record. Pass `--no-wait` to return as soon as the load balancer exists. A load balancer created with `datumctl alb create` starts with the following defaults: * **Force HTTPS:** on. HTTP requests are redirected to HTTPS. To turn it off, pass `--no-force-https`. * **Traffic protection:** `Enforce` at sensitivity 1. To change it, pass `--waf-mode Observe` or `--paranoia LEVEL`, or pass `--no-waf` to create the load balancer without a policy. Before you put an existing site behind it, see [Roll out traffic protection safely](https://datum.net/docs/alb/operations/traffic-protection.md). * **Load balancing:** least request, with health checks off. See [Load balancing and health checks](https://datum.net/docs/alb/configuration/load-balancing.md). A load balancer that `datumctl compute deploy --http-port` attaches to a workload doesn't use these defaults. To check what a load balancer has, run `datumctl alb describe ALB_NAME`. The following flags change what you create: | Flag | What it does | | - | - | | `--endpoint URL` | Adds a URL origin. Repeat it to split requests evenly across several origins. | | `--network-service NAME --port PORT_NAME` | Sends traffic to an existing [network service](https://datum.net/docs/galactic-vpc/networks/network-services.md) on its named port, such as `http`. Repeat the pair for several services. | | `--hostname HOSTNAME` | Attaches a custom hostname at create time. See [Serve traffic on your own domain](https://datum.net/docs/alb/operations/custom-domains.md). | | `--host-header HOST` | Sets the Host header that Datum sends to the origin. | | `--tls-hostname HOSTNAME` | Sets the hostname that Datum uses to verify TLS when an `--endpoint` origin is an IP address. | | `--display-name NAME` | Sets the name shown in the Cloud Portal. If you omit `ALB_NAME`, Datum derives one from the display name. | | `--dry-run` | Validates the load balancer with the API server without creating it. | For example, to put a load balancer in front of a workload's network service and attach a custom hostname, run the following command: ```bash theme={null} datumctl alb create my-app \ --network-service storefront --port http \ --hostname app.example.com ``` ## Inspect a load balancer To see a load balancer's status, hostnames, routes, traffic protection, and certificates, run the following command: ```bash theme={null} datumctl alb describe ALB_NAME ``` `Status: Active` means Datum has published the configuration. It doesn't mean a request has succeeded, so confirm with a request such as `curl -I https://HOSTNAME/`. ## How changes roll out You change a load balancer in one place, your project, and Datum rolls the change out to Envoy in every Datum location. There's nothing to deploy per location and no capacity to change: Datum runs and scales the proxies. For how this works, see [Envoy](https://datum.net/docs/platform/envoy.md). A change that Datum accepts is published within seconds, but each location applies it on its own schedule. For a short time, some locations can serve the old configuration and others the new one. A change doesn't drop connections that are already open. To confirm a change, make a request rather than reading status. If a change seems to have no effect, see [A change that was accepted and never took effect](https://datum.net/docs/alb/troubleshooting.md#a-change-that-was-accepted-and-never-took-effect). ## Update a load balancer The `datumctl alb` plugin changes one part of a load balancer at a time: * **Hostnames:** see [Serve traffic on your own domain](https://datum.net/docs/alb/operations/custom-domains.md). * **Routes and origins:** see [Send paths to different origins](https://datum.net/docs/alb/operations/routes.md). * **Origin weights, load balancing, and health checks:** see [Load balancing and health checks](https://datum.net/docs/alb/configuration/load-balancing.md). * **Traffic protection:** see [Roll out traffic protection safely](https://datum.net/docs/alb/operations/traffic-protection.md). * **Basic authentication:** run `datumctl alb auth set`. See [Authentication](https://datum.net/docs/alb/authentication/overview). To change the underlying resources directly, edit the `HTTPProxy` and `TrafficProtectionPolicy` and apply them with `datumctl apply`. See [HTTPProxy](https://datum.net/docs/alb/httpproxy/overview). ## Delete a load balancer To delete a load balancer, run the following command: ```bash theme={null} datumctl alb delete ALB_NAME --yes ``` This also removes the traffic protection policy and any basic authentication attached to it. If you create a load balancer again with the same name, it gets a new generated hostname, so update any `CNAME` records that pointed at the old one. Without `--yes`, the command asks you to type the name to confirm. A load balancer that `datumctl compute deploy` attached to a workload is deleted with the workload by `datumctl compute destroy`. See [Compute operations](https://datum.net/docs/compute/operations#delete-a-workload). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.