Vinyl Cache

Sign in to the Azure Portal, choose Create a resource, and search the Marketplace for Vinyl Cache by SecureAnyCloud. Select the listing and choose Create.

On the Basics tab, pick your subscription, resource group, region and a VM size (Standard_B2s or larger). Under Administrator account, select SSH public key, set the username and paste your public key.

Under Inbound port rules, allow SSH (22) for administration and HTTP (80) for the cache. Scope HTTP to the clients or CDN that will use it. Select Review + create, then Create. First-boot initialisation completes within a few seconds of the VM reaching the Running state.

Run the following commands to create a VM from this image in an existing VNet and subnet. Replace the values in angle brackets with your own.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:vinyl-cache-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name vinyl-cache \
  --image sac1647283583153:vinyl-cache-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
# Allow the cache port from the clients / CDN that will use it.
az vm open-port --resource-group <your-rg> --name vinyl-cache --port 80 --priority 1010

Connect to the VM as the administrator user you set at deploy time, azureuser by default on Ubuntu. The administrator account accepts SSH keys only.

ssh azureuser@<vm-public-ip>

Vinyl Cache starts automatically on boot. Check that the cache service and the bundled demo origin are active, and list the listen sockets:

systemctl is-active vinyl-cache.service vinyl-origin.service
sudo ss -tlnp | grep -E ':(80|6082|8080)'

The cache listens on 0.0.0.0:80, the public accelerator port. The management interface (127.0.0.1:6082) and the bundled demo origin (127.0.0.1:8080) are bound to the loopback address only. Expected output:

active active LISTEN 0 1024 127.0.0.1:6082 0.0.0.0:* users:(("vinyld",...)) LISTEN 0 1024 127.0.0.1:8080 0.0.0.0:* users:(("nginx",...)) LISTEN 0 10 0.0.0.0:80 0.0.0.0:* users:(("vinyld",...)) LISTEN 0 10 [::]:80 [::]:* users:(("vinyld",...))

The image ships pointed at a bundled demo origin, so you can verify caching immediately. Send the same request twice through the cache and watch the X-Cache response header. The first uncached request is a MISS, and every later request is served from cache as a HIT. The X-Cache-Hits counter shows how many times the object has been served from cache.

curl -s -D - -o /dev/null http://127.0.0.1/ | grep -i '^x-cache'
curl -s -D - -o /dev/null http://127.0.0.1/ | grep -i '^x-cache'
sudo vinylctl hitcheck

Expected output (the second and later requests are cache hits):

X-Cache: HIT X-Cache-Hits: 5 X-Cache: HIT X-Cache-Hits: 6 X-Cache: HIT X-Cache-Hits: 7

You can also read the cache counters directly. MAIN.cache_hit increases with every request served from cache:

sudo vinylstat -n /run/vinyl -1 -f MAIN.cache_hit -f MAIN.cache_miss

Use the vinylctl tool to replace the bundled demo origin with your own web origin. Substitute your origin's host and port for the example value below:

sudo vinylctl backend 10.1.0.10:8080
# your origin host:port
sudo vinylctl status

vinylctl backend rewrites the backend definition in /etc/vinyl/default.vcl and reloads the cache with no downtime. To review the current backend, the listen sockets and the cache hit counter at any time, run:

sudo vinylctl status

The Backend origin block shows where the cache forwards uncached requests. The Cache hit counter shows how much traffic is served from cache.

Read the first-boot information file at any time. It records the private IP of the server and the exact command to point the cache at your origin:

sudo cat /root/vinyl-cache-info.txt
sudo stat -c '%a %U:%G' /etc/vinyl/secret

The management interface (127.0.0.1:6082) is bound to the loopback address only. It is authenticated by a per-VM secret at /etc/vinyl/secret, mode 600 root:root.

That secret is generated fresh on the first boot of every VM and never shipped in the image. No two deployments share a management credential, and there is no baked-in default to leak. Only the cache port (80) and SSH are reachable from the network. The management interface and the demo origin never leave the loopback address.

echo -n 'public TCP ports: ';
sudo ss -tlnH | awk '{print $4}' | grep -vE '^(127\.|\[::1\])' | awk -F: '{print $NF}' | sort -un | paste -sd' ' -

The only publicly bound ports are 22 (SSH) and 80 (the cache). The management interface is never exposed.

The caching policy lives in /etc/vinyl/default.vcl. The shipped policy caches GET and HEAD responses, strips client cookies on the demo path, and adds the X-Cache header so you can observe cache behaviour.

Edit the file to tune which paths to cache, time to live and header handling. Then reload with no downtime:

sudo nano /etc/vinyl/default.vcl
sudo vinylctl reload

vinylctl reload recompiles the configuration and activates it with no dropped connections. If the configuration has a syntax error, the reload is refused and the running cache keeps serving, so a bad edit never takes the cache down.

The vinylctl tool is the primary interface to the cache:

Command Purpose

vinylctl status Show the service state, listen sockets, backend origin and cache hit counter

vinylctl backend <host:port> Point the cache at your origin and reload

vinylctl reload Recompile and reload the configuration in /etc/vinyl/default.vcl

vinylctl hitcheck Prove caching: send requests through the cache and show the X-Cache header

The cache service is a standard systemd unit, so you can also manage it with systemctl:

sudo systemctl status vinyl-cache.service
sudo systemctl restart vinyl-cache.service

The image is hardened out of the box. The management interface binds to the loopback address only and is protected by a per-VM secret. Only the cache port and SSH are public, and the bundled demo origin is confined to the loopback address.

In production, keep it locked down:

• Scope the NSG rule for TCP 80 to the clients or CDN that need the cache
• Never expose the management interface
• Keep your VCL caching policy scoped to the paths you intend to cache
• Keep the OS patched (sudo apt update && sudo apt upgrade)
• Put TLS termination (a load balancer or a TLS front end) in front of the cache for HTTPS traffic

Consult the Vinyl Cache documentation for the full configuration language reference.