kunalmohan-work · Oct 19, 2026 · Oct 13, 2026 · Oct 13, 2026 · Oct 13, 2026 · Oct 16, 2026
diff --git a/docs/.custom_wordlist.txt b/docs/.custom_wordlist.txt
@@ -9,12 +9,14 @@ Autoscaling
 aws
 backend
 backends
+backoff
 backport
 bcrypt
 blocklisted
 blocklisting
 boolean
 bugfixes
+burstable
 Canonical('s)?
 Charmcraft
 charmstore
@@ -28,6 +30,8 @@ Diátaxis
 docstrings?
 downloader
 Downloader
+downscoped
+downscoping
 dvipng
 enablement
 Enablement
@@ -82,13 +86,15 @@ Multipass
 MyST
 npm
 Numpy
+OAuth
 oem
 OCI
 Open Graph
 openapi
 otf
 patchstore
 PDF
+permissionless
 plaintext
 plantuml
 PNG
@@ -97,6 +103,8 @@ PPAs
 PR
 PRs
 preconfigured
+presigned
+Presigned
 proxying
 Pygments
 pymarkdown
@@ -139,6 +147,7 @@ TOC
 toctree
 triages
 txt
+uploader
 ulwazi
 unapplied
 uncomment(ing)?

diff --git a/...ides/configuration/enable-and-configure-the-livepatch-client-with-cloud-init.md b/...ides/configuration/enable-and-configure-the-livepatch-client-with-cloud-init.md
@@ -75,13 +75,13 @@ Any configuration values that do not require changes should be removed from the
 The cloud-init module for using the client with an on-premises Livepatch Server is similar to the previous module. Instead of the Pro token, use an auth token generated by the admin tool:
 
 ```bash
-canonical-livepatch-server-admin.livepatch-admin auth-token <sso-id> <tier> [flags]
+sudo canonical-livepatch-server-admin.livepatch-admin auth-token <sso-id> <tier> [flags]
 ```
 
 For example:
 
 ```bash
-canonical-livepatch-server-admin.livepatch-admin auth-token test edge
+sudo canonical-livepatch-server-admin.livepatch-admin auth-token test edge
 ```
 
 This command outputs an auth token that can be used with client machines to apply patches in the `edge` tier.

diff --git a/docs/server/how-to-guides/deployment/deploy-via-juju.md b/docs/server/how-to-guides/deployment/deploy-via-juju.md
@@ -127,9 +127,7 @@ See the [Administration Tool guide](/server/how-to-guides/security/setup-adminis
 Once this has been done, the Livepatch admin tool can be used to authenticate:
 
 ```
-export LIVEPATCH_URL=http(s)://{haproxy url}
-
-livepatch-admin login -a [username:password]
+sudo livepatch-admin --url http(s)://{haproxy url} login -a [username:password]
 ```
 
 ### 5. Download patches
@@ -139,7 +137,7 @@ The final step before attaching client machines to the server is to download pat
 To download patches, run:
 
 ```
-livepatch-admin sync trigger --wait
+sudo livepatch-admin sync trigger --wait
 ```
 
 ## Enable machine status reporting

diff --git a/docs/server/how-to-guides/deployment/deploy-via-snap.md b/docs/server/how-to-guides/deployment/deploy-via-snap.md
@@ -88,11 +88,7 @@ To manage Livepatch, an administrator tool is available as a snap. Install it wi
 sudo snap install canonical-livepatch-server-admin
 ```
 
-The administrator tool needs to know where the Livepatch Server is hosted. In an all-in-one setup on a single machine, this is `http://localhost:8080`. Export an environment variable as follows:
-
-```
-export LIVEPATCH_URL=http://localhost:8080
-```
+The administrator tool needs to know where the Livepatch Server is hosted. In an all-in-one setup on a single machine, this is `http://localhost:8080`. Use the `--url` flag in the command to specify the address.
 
 ## Set up authentication
 
@@ -121,15 +117,15 @@ sudo snap set canonical-livepatch-server lp.auth.basic.enabled=true
 Finally, log in with the administrator tool, assuming the example username and password have been used:
 
 ```
-canonical-livepatch-server-admin.livepatch-admin login -a admin:admin123
+sudo canonical-livepatch-server-admin.livepatch-admin login -a admin:admin123
 ```
 
 ## Synchronize with hosted Livepatch
 
 Once the on-premises Livepatch Server is running and fully configured, synchronize patches from hosted Livepatch into the server. Run the following within the administrator tool:
 
 ```
-canonical-livepatch-server-admin.livepatch-admin sync trigger
+sudo canonical-livepatch-server-admin.livepatch-admin sync trigger
 ```
 
 To set the server to automatically sync patches from Canonical's servers every 12 hours, run:
@@ -160,11 +156,7 @@ To listen for all incoming connections on a different port, run:
 sudo snap set canonical-livepatch-server lp.server.server-address=0.0.0.0:<port>
 ```
 
-Update the `LIVEPATCH_URL` environment variable to ensure the admin tool can still access the server. To access the server from a remote machine, replace `localhost` with the IP address of the machine running the Livepatch Server:
-
-```
-export LIVEPATCH_URL=http://localhost:<port>
-```
+Be sure to include the correct server endpoint with the `livepatch-admin` commands using the `--url` flag.
 
 ## Next steps
 

diff --git a/...r/how-to-guides/deployment/migrate-from-reactive-charm-to-k8s-operator-charm.md b/...r/how-to-guides/deployment/migrate-from-reactive-charm-to-k8s-operator-charm.md
@@ -260,7 +260,7 @@ If the same database is being used for patch storage as for the main Livepatch S
 After migrating the database, ensure access to the patches by querying for available patches via the admin tool:
 
 ```bash
-canonical-livepatch-server-admin.livepatch-admin storage patches
+sudo canonical-livepatch-server-admin.livepatch-admin storage patches
 ```
 
 If the migration was successful, a list of patch payloads for each patch version will be displayed.
@@ -272,7 +272,7 @@ The `swift` and `s3` patch storage types imply that the patches are stored in a
 When using object storage, such as AWS S3 or a Swift bucket, relevant connection parameters have been copied over with the configuration migration. The only required action is to refresh the patch storage:
 
 ```bash
-canonical-livepatch-server-admin.livepatch-admin storage refresh
+sudo canonical-livepatch-server-admin.livepatch-admin storage refresh
 ```
 
 This adds patches found in storage to the distribution records in the Livepatch database.
diff --git a/docs/server/how-to-guides/deployment/migrate-from-reactive-charm-to-snap.md b/docs/server/how-to-guides/deployment/migrate-from-reactive-charm-to-snap.md
@@ -236,8 +236,8 @@ The `livepatch-admin` tool is useful for syncing patches from the upstream Livep
 1. [Set up the livepatch-admin tool](/server/how-to-guides/security/setup-administration-tool.md)
 2. [Fetch patches from the hosted Livepatch Server](/server/how-to-guides/patch-management/fetch-patches.md)
 
-Once the patches have been downloaded, run `livepatch-admin storage refresh` to sync the patch storage and patch data in the database.
+Once the patches have been downloaded, run `sudo livepatch-admin storage refresh` to sync the patch storage and patch data in the database.
 
 ```{note}
-It is recommended to run `livepatch-admin storage refresh` after the database and patch migration, irrespective of the type of patch storage and how the migration was done, as it helps confirm that both the patch data in the database and the patches in the storage are in sync.
+It is recommended to run `sudo livepatch-admin storage refresh` after the database and patch migration, irrespective of the type of patch storage and how the migration was done, as it helps confirm that both the patch data in the database and the patches in the storage are in sync.
 ```
diff --git a/docs/server/how-to-guides/deployment/public-clouds/deploying-on-aws.md b/docs/server/how-to-guides/deployment/public-clouds/deploying-on-aws.md
@@ -20,8 +20,13 @@ To set up the Livepatch Server on AWS using an S3 bucket for patch storage, the
 * An Ubuntu Pro token stored in the AWS Secrets Vault.
 * An S3 bucket with the `s3:GetObject` policy. The bucket must be public for clients to download patches, but the policy can be restricted to a range of IP addresses.
 * An IAM role with the `AWSSecretsManagerClientReadOnlyAccess` role and `AmazonS3ReadOnlyAccess` role.
-* An IAM user with Allow effects for the actions `s3:PutObject`, `s3:ListBucket`, and `s3:GetObject` roles for the S3 bucket.
+* An IAM user with Allow effects for the actions `s3:PutObject`, `s3:ListBucket`, `s3:GetObject`, and `s3:DeleteObject` roles for the S3 bucket. `s3:DeleteObject` is required for patch removal and uploader rollback.
 * A secret entry for the IAM user with key-value pairs `S3AccessKey` (for the S3 access key) and `SecretAccessKey` (for the S3 secret key).
+
+```{note}
+The cloud-init template below uses static IAM access keys for the S3 bucket. As an alternative, the server can use the EC2 instance profile attached to the launch template (recommended) or STS AssumeRole. See the [authentication mechanisms](/server/reference/patch-storage/use-s3-for-patch-storage.md#supported-authentication-mechanisms) in the S3 reference for details.
+```
+
 * A load balancer set to internet-facing.
 * An auto-scaling group using the launch template.
 * A security group to allow all internet access for HTTP and HTTPS.
@@ -66,9 +71,8 @@ write_files:
       # S3 variables
       export S3_SECRET_ID=<s3 secret id>
       export S3BUCKET=<bucket name>
-      export S3ENDPOINT=<bucket endpoint>
-      export S3REGION=<region> 
-      export URLTEMPLATE=https://<bucket name>.s3-<region>.amazonaws.com/{filename}
+      export S3REGION=<region>
+      export URLTEMPLATE=https://<bucket name>.s3.<region>.amazonaws.com/{filename}
   - path: /etc/livepatch/database_url
     permissions: "0600"
     owner: root:root
@@ -135,7 +139,6 @@ runcmd:
     lp.patch-storage.type=s3 \
     lp.server.url-template=$URLTEMPLATE \
     lp.patch-storage.s3-bucket="$S3BUCKET" \
-    lp.patch-storage.s3-endpoint="$S3ENDPOINT" \
     lp.patch-storage.s3-region="$S3REGION" \
     lp.patch-storage.s3-secure=true \
     lp.patch-storage.s3-access-key="$(cat /etc/livepatch/s3 | jq -r '.S3AccessKey' )" \

diff --git a/docs/server/how-to-guides/deployment/public-clouds/deploying-on-azure.md b/docs/server/how-to-guides/deployment/public-clouds/deploying-on-azure.md
@@ -13,15 +13,16 @@ This section details how to deploy the Livepatch Server snap in auto-scaling con
 
 ## Required resources
 
-To set up the Livepatch Server on Azure using a filesystem or PostgreSQL (Azure Blob Storage is not yet supported) for patch storage, the following are required:
+To set up the Livepatch Server on Azure using an Azure Blob Storage container for patch storage, the following are required. For Blob Storage configuration, see [Use Azure for patch storage](/server/reference/patch-storage/use-azure-for-patch-storage.md).
 
 * A VNet with subnets for VMSS, Application Gateway, and PostgreSQL DB.
 * An Azure Key Vault with access enabled for the VMSS subnet of the VNet.
+* An Azure Storage account and Blob store container with access enabled for the VMSS subnet of the VNet.
 * An Azure-managed PostgreSQL instance with PostgreSQL 14 or above using password authentication. The username and password stored in Azure Key Vault as a JSON object.
 * A Virtual Machine Scale Set (VMSS) with an instance type with at least two vCPUs and 4 GB RAM, with a cloud-init configuration file as custom data.
 * An Ubuntu Pro token stored as a secret in Azure Key Vault.
 * Livepatch Server admin credentials stored in Azure Key Vault Secrets in `<username>:<hashedpassword>` format.
-* A Managed Identity with the `Key Vault Secrets User` role in Azure Key Vault.
+* A Managed Identity with the `Key Vault Secrets User` role in Azure Key Vault. For using Azure Blob Storage for patch storage, also assign it the `Storage Blob Data Contributor` and `Storage Blob Delegator` roles on the storage account.
 * An Application Gateway with a public IP address as an entry point for accessing the Livepatch Server.
 * A VMSS as a backend pool with the corresponding Managed Identity attached.
 
@@ -39,15 +40,15 @@ Create an Azure-managed PostgreSQL DB with PostgreSQL password authentication. D
 
 ### Create the Managed Identity
 
-Create a Managed Identity. This will be assigned to the VMSS to allow access to Azure Key Vault.
+Create a Managed Identity. This will be assigned to the VMSS to allow access to Azure Key Vault. To use Azure Blob Storage for patch storage, the same identity is used for storage access — assign the **Storage Blob Data Contributor** and **Storage Blob Delegator** roles on the storage account to it (see the [reference](/server/reference/patch-storage/use-azure-for-patch-storage.md)).
 
 ### Create the Azure Key Vault
 
 Create an Azure Key Vault with public access disabled. Allow access from the VMSS subnet of the VNet. Store the DB credentials (JSON format), admin credentials (`<username>:<hashedpassword>` format), and Pro token (raw string) in the Key Vault. Assign the `Key Vault Secrets User` role for this Vault to the Managed Identity.
 
 ### Configure the VMSS
 
-For VMSS, select an instance type with sufficient CPU and memory capacity. The minimum resources required for the Livepatch Server to run efficiently are two vCPUs and 4 GB memory. Avoid using B-series instances. For storage options, the default volume size of 30 GB is sufficient. Assign the Managed Identity to the VMSS to allow access to Azure Key Vault.
+For VMSS, select an instance type with sufficient CPU and memory capacity. The minimum resources required for the Livepatch Server to run efficiently are two vCPUs and 4 GB memory. For storage options, the default volume size of 30 GB is sufficient. Assign the Managed Identity to the VMSS to allow access to Azure Key Vault.
 
 Configure the VMSS NSG to allow traffic on port 80 from within the VNet. It is recommended not to have public IP addresses assigned to the VMSS VMs. This ensures that VMs can be accessed only through the Application Gateway. Provision a jumpbox in the same VNet with a public IP to access VMs when required.
 
@@ -77,6 +78,10 @@ write_files:
       export DB_SECRET_ID=<db secret id>
       export DB_NAME=<db name>
 
+      # patch store
+      export STORAGE_ACCOUNT_NAME=<account name>
+      export STORAGE_CONTAINER=<container>
+
       # pro token variables
       export TOKEN_SECRET_ID=<token secret id>
       export ADMIN_USER_SECRET_ID=<admin user secret id>
@@ -154,9 +159,11 @@ runcmd:
     snap set canonical-livepatch-server \
     token="$(cat /etc/livepatch/pro_token)" \
     lp.database.connection-string="$(cat /etc/livepatch/database_url)" \
-    lp.patch-storage.type=postgres \
+    lp.patch-storage.type=azure \
     lp.server.url-template=$URLTEMPLATE \
-    lp.patch-storage.postgres-connection-string="$(cat /etc/livepatch/database_url)" \
+    lp.patch-storage.azure-account-name=$STORAGE_ACCOUNT_NAME \
+    lp.patch-storage.azure-container=$STORAGE_CONTAINER \
+    lp.patch-storage.azure-managed-identity-client-id="$AZURE_MANAGED_IDENTITY_CLIENT_ID" \
     lp.auth.basic.enabled=true \
     lp.patch-sync.enabled=true \
     lp.patch-sync.interval=12h \
@@ -172,6 +179,17 @@ final_message: The system is up, up to date, and Livepatch Server is active afte
 
 Ensure the correct environment variable values are filled in the `write_files` section of the configuration.
 
+### Use Azure Blob Storage
+
+To use Azure Blob Storage for patch storage, grant the Managed Identity the storage roles as described in [Create the Managed Identity](#create-the-managed-identity), then set the patch storage type to `azure` in the `snap set` command. When using a system-assigned managed identity, no `azure-account-key`, `azure-connection-string`, or service-principal keys are set — the server uses the ambient identity. Note that `patch-storage.azure-account-name` is still required:
+
+```bash
+sudo snap set canonical-livepatch-server \
+  lp.patch-storage.type=azure \
+  lp.patch-storage.azure-container=<container-name> \
+  lp.patch-storage.azure-account-name=<storage-account-name>
+```
+
 ### Provision the Application Gateway
 
 Provision a Standard V2 (or WAF V2) Application Gateway in the subnet created in the VNet with autoscaling enabled. The minimum instance count should be set according to the expected traffic. Add the VMSS to the backend pool of the Application Gateway and route all traffic to this pool. Use port 80 with `GET /` as the health check endpoint for the VMSS.