Chroma or VecturaDB on an Azure VM

One server in your own Azure subscription, with its data on a managed disk, HTTPS, allowed IP addresses and backups. From about 14 USD a month on your Azure bill.

What it creates

The template runs one of two servers:

• Chroma 1.5.9, the open-source single-node server (ghcr.io/chroma-core/chroma:1.5.9);
• VecturaDB 1.0.0-preview.3.post1, built from Chroma, with sparse vectors, BM25, hybrid search, collection fork and API keys.

Both keep the Chroma API: the Chroma clients connect with the URL of the deployment. In our tests the Python (chromadb 1.5.9) and JavaScript (chromadb 3.5.0) clients and a .NET client gave the same results on the two servers.

Deploy

Deploy to Azure

The button opens the form of the Azure portal with the template of the tag azure-v1.1.0. When the portal shows “Your deployment is complete”, open Outputs in the menu on the left: url is the address of the server, for the clients.

With the Azure CLI:

az group create -n my-chroma -l westeurope
az deployment group create -g my-chroma \
  --template-uri https://raw.githubusercontent.com/VecturaDB/VecturaDB.Deploy/azure-v1.1.0/azure/vm/azuredeploy.json \
  -p access=allowed-ips allowedIpRanges='["203.0.113.10/32"]' \
     adminPublicKey="$(cat ~/.ssh/id_ed25519.pub)"

For VecturaDB with an API key, add engine=vecturadb apiKey=<your key>. The template, its scripts and its README are in the VecturaDB.Deploy repository, under azure/vm.

Access and HTTPS

• Caddy gets a Let's Encrypt certificate and forwards to the server on 127.0.0.1.
• Port 80 answers only the challenge of the certificate.
• Ports 22 and 8000 stay closed.
• The deployment ends only when Caddy holds the certificate.
• Chroma 1.5.9 has no API keys: public access needs VecturaDB with a key, sent in the x-chroma-token header.

Cost

The sizes we tested, with the list prices of westeurope in USD for 730 hours a month, on 26 October 2026:

• With internal access there is no public IP: 3.65 USD less.
• Not in the table: disk transactions, outbound traffic and the snapshots of the backups.
• Standard_B1ls does not work: in our tests it ran out of memory at the first boot.
• B1s and B1ms belong to the Bv1 series, which Azure lists as End of Life: that is why the default is B2pts_v2.
• B-series sizes stay at a baseline CPU once their credits run out: 20% for B2pts_v2 (Bpsv2 series). A server that is busy all the time needs another size.
• A new Azure free account includes, for 12 months, "750 hours each of B1s, B2pts v2 (Arm-based), and B2ats v2 (AMD-based) burstable VMs" (details).
• With 1 GiB of memory, Chroma used 54-61 MiB at rest. We measured only small collections: Chroma keeps its vector index in memory, so a large collection needs a larger size.

Backups and restore

• With backups on, the default, Azure Disk Backup takes incremental snapshots of the data disk every 24 hours, or every 4, 6, 8 or 12 hours, and keeps them 7 days.
• Azure Disk Backup has no fee per protected disk. The snapshots are billed at the price of standard storage, 0.05 USD per GB a month in westeurope: the first one for the used part of the disk, the next ones for the changes.
• Soft delete is on: deleted backups stay 14 days.
• The snapshots are taken while the server runs, so a restored disk is like a disk after a power cut. In our tests the server started on it with all the data of the backup.

Restore

1. In the backup vault, restore a recovery point to a new disk in the same resource group: Backup instances, then Restore.
2. Attach the new disk at LUN 1 and run restore.sh: it copies the data of the backup over the data disk and starts the server again.
3. Detach and delete the new disk.

az vm disk attach -g my-chroma --vm-name chroma --name <restored disk> --lun 1
az vm run-command invoke -g my-chroma -n chroma --command-id RunShellScript --scripts @restore.sh
az vm disk detach -g my-chroma --vm-name chroma --name <restored disk>
az disk delete -g my-chroma -n <restored disk>

The data written after the backup is lost: take an on-demand backup first if you may want it back. The data disk stays the same, so the backups go on.

After the restore the server held the data of the backup, and not the data written after it.

Updates

• To change the server, its image or the access, deploy the template again: it stops the old container and starts the new one, with the data on the data disk.
• The server does not answer during the switch.
• Docker starts only once the data disk is mounted: a VM that boots without it serves nothing, rather than an empty database.
• Ubuntu installs its security updates by itself. Caddy comes from its own repository: you update it.

Delete everything

Deleting the resource group deletes the deployment, the snapshots of the backups included. With backups on, two things stop it first: the backup instance of the data disk, and the soft delete of the vault, on by default. So turn soft delete off, delete the backup instance, then delete the group. Without backups, delete the group.

In the portal

1. Open the backup vault, <name>-backup. Under Manage, open Properties. In Cyber recovery settings, on the Soft delete row, select Update, clear Enable Soft Delete, and select Update.
2. Under Manage, open Backup instances. The filter starts on another datasource type, so the list looks empty: set Datasource type to Azure Disks, and open <name>-data.
3. Select Delete. Type the name of the instance, choose a reason and write a comment: all three are required. Select Delete, then Confirm.
4. Open the resource group and select Delete resource group. Type the name of the group, select Delete, then Delete again to confirm.

With the Azure CLI

SUB=$(az account show --query id -o tsv); RG=my-chroma; NAME=chroma
VAULT="https://management.azure.com/subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.DataProtection/backupVaults/$NAME-backup"
az rest --method patch --url "$VAULT?api-version=2024-04-01"   --body '{"properties":{"securitySettings":{"softDeleteSettings":{"state":"Off","retentionDurationInDays":14}}}}'
az rest --method delete --url "$VAULT/backupInstances/$NAME-data?api-version=2024-04-01"
# The deletion goes on in the background: wait until the backup instance is gone.
while az rest --method get --url "$VAULT/backupInstances/$NAME-data?api-version=2024-04-01" -o none 2>/dev/null; do sleep 10; done
az group delete -n $RG --yes

Then nothing was left: no resource, no snapshot, no deleted vault.

If you skip these steps

• With the backup instance still there, the deletion of the group failed after 438 seconds. Everything else was gone, and the group and the vault stayed.
• With the backup instance deleted and soft delete still on, the instance stayed soft deleted for 14 days, and so did the vault and the group. Microsoft says that snapshots still there during those days are billed (soft delete for Azure Backup).

The README of the template also says how to get out of the soft-deleted state before the 14 days.

Limits

• One VM and one disk: no high availability.
• While the VM restarts or a deployment switches the container, the server does not answer.
• A new deployment restarts the server, even when nothing changes.
• The backups are snapshots in the same region.
• A disk attached by hand at LUN 0 needs --caching ReadOnly, as the template sets it: otherwise a later deployment changes the caching, and Azure detaches and attaches the disk while the VM runs.