Chroma on Azure Container Apps

Chroma 1.5.9 on Azure Container Apps, with the data on an Azure Files share. The app scales to zero when nobody uses it, so it costs almost nothing on idle days.

What it creates

The server reaches the share through two mounts:

• the data, with nobrl: byte-range locks stay on the replica. With the locks sent to the server, Chroma 1.5.9 did not start in our tests;
• a lock file, without nobrl: its lock reaches the server, so it holds across replicas and hosts. A new replica waits for it before it starts the server.

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/container-apps/azuredeploy.json \
  -p allowedIpRanges='["203.0.113.10/32"]'

The template and its README are in the VecturaDB.Deploy repository, under azure/container-apps.

Access and HTTPS

• HTTPS comes from Container Apps, on the Azure name of the app.
• No API keys: Chroma 1.5.9 has none, so the template has no public access.

Cost

Container Apps bills the seconds a replica runs: active while it serves, at a lower rate while it waits before scaling to zero. The first 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests of each month are free, for the whole subscription.

With 0.5 CPU and 1 GiB, at the list prices of westeurope in USD on 27 October 2026:

Not in the table:

Other apps in the same subscription use the same free grant.

Backups and restore

No backups: the template does not back up the share. Soft delete keeps a deleted share for 7 days, but it does not bring back data that was changed or deleted inside it. For backups, use the VM template.

Updates

A new deployment, with other settings or another image, creates a new revision. Its replica waits for the lock held by the old one, and the deployment ends anyway.

• While the app is in use: deactivate the old revision, the one that is not Activating, within 5 minutes.
• While the app has no replica, about 10 minutes after the last request: nothing to do. Nothing holds the lock, and the old revision goes away by itself.

az containerapp revision list -g my-chroma -n chroma --query "[?properties.active].{name:name, state:properties.runningState}" -o table
az containerapp revision deactivate -g my-chroma -n chroma --revision <the old revision, the one that is not Activating>

In our tests the old revision kept serving while the new one waited, and the new revision answered with all the data.

Delete everything

There is no backup vault here: deleting the resource group deletes the whole deployment. In the portal, 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:

az group delete -n my-chroma --yes

Two things stay recoverable for 14 days after the deletion, as Azure does for these resources, and then go away:

• the storage account, with the share and the data in it (recover a deleted storage account);
• the Log Analytics workspace, with the logs (delete and recover a workspace).

To remove the logs at once, delete the workspace permanently before the group:

az monitor log-analytics workspace delete -g my-chroma -n chroma-logs --force --yes

Limits

• An update made while the app is in use needs a manual step: see Updates.
• After about 10 minutes without requests the app scales to zero, and the next request waits: set the timeout of your client above that.
• One replica at most: no horizontal scale.
• Slower than the VM: the data sits on a network share.
• No backups, and no API keys.
• A lock can outlive its replica: see A lock left by a lost replica.

Medians from a client in the same region, in milliseconds:

A lock left by a lost replica

When the host of the replica disappears without closing its files, Azure Files keeps the lock on the lock file until it gives up on that host. Until then the next replica waits, and the server does not answer. To free the lock earlier, close only the handle of the lost replica:

ACCOUNT=$(az storage account list -g my-chroma --query "[0].name" -o tsv)
KEY=$(az storage account keys list -g my-chroma -n $ACCOUNT --query "[0].value" -o tsv)
az storage share list-handle --account-name $ACCOUNT --account-key $KEY --name data --path .lock -o table
az storage share close-handle --account-name $ACCOUNT --account-key $KEY --name data --path .lock \
  --handle-id <the handle of the lost replica>

The list shows a handle for each replica that opened the file, with its client IP and the time it was opened: the lost replica is the older one. Never use --close-all: in our tests it also closed the handle of the process that was waiting, which then failed with an input/output error.