LanCache

Open Marketplace in the Azure Portal, search for LanCache, select the SecureAnyCloud publisher entry, and choose Create.

On the Networking tab, attach a network security group. It must allow inbound TCP 22 from your management IP range, and inbound UDP+TCP 53, TCP 80 and TCP 443 from your client source ranges.

Choose Review + create, wait for validation, then choose Create. Deployment takes around two minutes.

RG="lancache-prod" LOCATION="eastus" VM_NAME="lancache-01" ADMIN_USER="azureuser" IMAGE_URN="sac1647283583153:lancache-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:lancache-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" \
  --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --size Standard_B2s \
  --admin-username "$ADMIN_USER" \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
# Open the LanCache ports (scope the source ranges to your client networks)
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 53 --priority 1010
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 80 --priority 1020
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 443 --priority 1030

Once the VM is running, connect over SSH as your admin user.

ssh azureuser@<vm-ip>

First boot resolves this VM's public IP and starts the cache and the DNS. Confirm that the two containers are up, that the DNS/HTTP/HTTPS ports are listening, and that the cache heartbeat is healthy.

sudo docker ps --format '{{.Names}} {{.Status}}' systemctl is-active docker lancache-firstboot
sudo ss -lntup | grep -E ':53 |:80 |:443 ' curl -s -o /dev/null -w 'heartbeat -> HTTP %{http_code}\n' http://127.0.0.1/lancache-heartbeat

You should see lancache-monolithic and lancache-dns both Up, docker and lancache-firstboot both active, sockets listening on 53, 80 and 443, and the heartbeat returning HTTP 204.

The DNS answers the cached CDN domains with this VM's IP and refuses everything else. Run the commands below. They use the first domain from the shipped allow-list, and the appliance serves well over a hundred CDN domains.

CACHE_IP=$(sudo grep '^LANCACHE_IP=' /root/lancache-credentials.txt | cut -d= -f2-)
CDN=$(head -1 /var/lib/lancache/dns/cache-domains.txt)
echo "cache IP = $CACHE_IP sample cached domain = $CDN"
# A cached CDN domain (and any subdomain of it) resolves to this cache dig +short @127.0.0.1 "$CDN" A dig +short @127.0.0.1 "sub.$CDN" A
# An arbitrary domain is REFUSED - this is NOT an open resolver dig @127.0.0.1 example.com A | grep -E 'status:'

The two dig +short lookups return the cache IP. The example.com lookup returns status: REFUSED with no answer. That is the appliance refusing to recurse for anything outside its allow-list.

The cache serves the allow-listed CDNs only. An arbitrary HTTP Host is refused (not proxied), and an arbitrary TLS SNI is dropped (not relayed). Run the commands below to check both.

CDN=$(head -1 /var/lib/lancache/dns/cache-domains.txt)
# A request for a cached CDN domain is handled by the lancache cache (X-LanCache header)
curl -s -D - -o /dev/null -H "Host: $CDN" http://127.0.0.1/lancache-heartbeat | grep -iE 'HTTP/|X-LanCache'
# An arbitrary HTTP Host is refused - the connection is closed, so curl exits non-zero curl -s -o /dev/null -H 'Host: example.com' http://127.0.0.1/ ; echo "arbitrary HTTP Host -> curl exit $? (non-zero / refused = not an open proxy)"
# An arbitrary TLS SNI relays no upstream certificate
CERTS=$(timeout 8 openssl s_client -connect 127.0.0.1:443 -servername example.com </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE')
echo "arbitrary TLS SNI -> certificates relayed: $CERTS (0 = not an open TLS relay)"

Point your clients' DNS at this VM to start caching. The appliance answers only the cached CDN domains (with its own IP) and refuses everything else, so it is not a general-purpose resolver. There are two common ways to use it:

• Conditional forwarding (recommended): On your existing DNS server or router, forward only the lancache CDN domains to this VM. Keep your normal resolver for everything else, so general browsing keeps working through your usual DNS.
• Per-client: Set the DNS server on the machines you want to cache to this VM's IP. Add a secondary DNS for general name resolution.

The per-VM appliance info file records this VM's IP and how to use it. The container images are pinned by digest. Read both below.

sudo cat /root/lancache-credentials.txt
sudo docker images --digests --format '{{.Repository}} {{.Digest}}' | grep lancachenet df -h /

Once clients resolve a cached CDN through this VM, their first download of a given file fills the cache (a MISS). Every later machine that downloads the same file gets it from the cache at LAN speed (a HIT). No client-side software is needed, because the caching is transparent.

Cache data lives under /var/lib/lancache on the OS disk, which ships at 64 GiB. A game or content cache can grow large, so give it more storage for anything beyond casual use. Choose one of these options:

• Resize the OS disk in the Azure Portal (VM > Disks > the OS disk > Size), then reboot. Ubuntu grows the root filesystem automatically.
• Attach a data disk, format and mount it at /var/lib/lancache, then reboot so first boot re-populates the cache directory on the larger volume.

The cache manages its own size. It evicts the least-recently-used objects to stay within its configured limit and keeps a minimum amount of free disk, so it will not fill the disk completely.