Hugging Face Chat UI

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Hugging Face Chat UI by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80). Then select Review + create and Create.

Create the network and the VM:

RG="chat-ui-prod"; LOCATION="eastus"; VM_NAME="chat-ui-01" IMAGE_URN="sac1647283583153:huggingface-chat-ui-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name cu-vnet --address-prefix 10.100.0.0/16 --subnet-name cu-subnet --subnet-prefix 10.100.1.0/24 az network nsg create -g "$RG" --name cu-nsg az network nsg rule create -g "$RG" --nsg-name cu-nsg --name allow-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name cu-nsg --name allow-http --priority 110 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 80 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:huggingface-chat-ui-ubuntu-24-04:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2ms --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name cu-vnet --subnet cu-subnet --nsg cu-nsg --public-ip-sku Standard

Connect over SSH as azureuser:

ssh azureuser@<vm-ip>

Chat UI runs as two containers under chat-ui.service, behind an nginx gateway on host port 80. Confirm that everything is active and see which images are running:

sudo systemctl is-active docker chat-ui-firstboot chat-ui nginx
sudo docker compose -f /var/lib/chat-ui/docker-compose.yml ps \
  --format 'table {{.Name}}\t{{.Status}}'

All four services report active, and both containers are Up:

active active active active NAME STATUS chat-ui Up 2 minutes chat-ui-mongo Up 2 minutes (healthy)

Both images are pinned by digest, so the VM you booted runs the exact images that SecureAnyCloud tested. Inspect the Chat UI image:

sudo docker inspect --format '{{index .Config.Labels "org.opencontainers.image.version"}} {{index .Config.Labels "org.opencontainers.image.licenses"}} {{index .Config.Labels "org.opencontainers.image.revision"}}' \
  ghcr.io/huggingface/chat-ui@sha256:41e450e64739b3ca45d7db1752de9a9eea11bb0829706f00b8dd7d3be016657b

The licence and the upstream commit are recorded in the image itself:

latest Apache-2.0 a33743a5c35ca0774ca82aadc2b49994a82e3d67

Commit a33743a5 is exactly what upstream git tag v0.9.6 points at.

A unique 32-character web credential and a unique MongoDB password were generated for this VM on its first boot, before anything was reachable. They were written to a root-only file. Read them:

sudo cat /root/chat-ui-credentials.txt

The file (mode 0600 root:root) holds CHAT_UI_URL, CHAT_UI_USERNAME, CHAT_UI_PASSWORD, MONGODB_USERNAME and MONGODB_PASSWORD. None of them ship in the image. Each is unique to this VM, so no two instances share one, and there is no default to change.

Browse to the CHAT_UI_URL from Step 5 - which is http://<vm-ip>/. The browser asks for a username and password. Enter chatui and the CHAT_UI_PASSWORD from the credentials file. Chat UI then loads with its model picker already populated from the configured endpoint.

Type a message and press Enter. The reply streams back token by token from the model endpoint. The conversation is titled automatically and appears in the sidebar, and everything is written to the MongoDB on this VM.

This is the most important section of this guide. Chat UI has no password login of its own. Upstream offers OpenID Connect single sign-on, and nothing else.

An instance left reachable on a public IP with a working model provider token would let anyone who finds the address spend your inference credit. This image closes that gap with an nginx gateway that denies every route by default, with a credential generated per VM.

Confirm that the gate refuses anything but your own credential:

B=http://localhost curl -s -o /dev/null -w 'no credentials: HTTP %{http_code}\n' $B/ curl -s -o /dev/null -w 'wrong password: HTTP %{http_code}\n' -u 'chatui:WRONGPASSWORD' $B/ curl -s -o /dev/null -w 'wrong username: HTTP %{http_code}\n' -u 'nobody:WRONGPASSWORD' $B/ curl -s -o /dev/null -w 'settings page: HTTP %{http_code}\n' $B/settings curl -s -o /dev/null -w 'models API: HTTP %{http_code}\n' $B/api/models echo -n 'liveness probe: '; curl -s $B/healthcheck; echo

Everything is refused with 401 except the static liveness probe. The probe returns the literal string OK and nothing else, so a load balancer never needs to hold this VM's credential:

no credentials: HTTP 401 wrong password: HTTP 401 wrong username: HTTP 401 settings page: HTTP 401 models API: HTTP 401 liveness probe: OK

Now send the same request with your password. Read the password straight out of the credentials file rather than typing it, so that it never lands in your shell history:

P=$(sudo grep -m1 '^CHAT_UI_PASSWORD=' /root/chat-ui-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'your credential: HTTP %{http_code}\n' -u "chatui:$P" http://localhost/

your credential: HTTP 200

The gate is fail-closed, not merely configured. Both services carry a preflight guard. The guard refuses to start if the credential file is missing, empty or holds a plaintext entry, or if the site configuration disables authentication anywhere but the liveness probe:

systemctl show -p ExecStartPre --value chat-ui.service | tr ';' '\n' | grep -o '/usr/local/sbin/[^ "]*'
systemctl show -p ExecStartPre --value nginx.service | tr ';' '\n' | grep -o '/usr/local/sbin/[^ "]*'
sudo /usr/local/sbin/chat-ui-preflight.sh --nginx --gate-file /dev/null; echo "exit=$?"

Both units run the guard, and the guard rejects an empty credential file rather than serving without one:

/usr/local/sbin/chat-ui-preflight.sh /usr/local/sbin/chat-ui-preflight.sh chat-ui-preflight: REFUSING TO START — /dev/null is empty — the HTTP Basic gate would accept nobody and protect nothing. exit=1

Change the password at any time by running sudo htpasswd -B /etc/nginx/chat-ui.htpasswd chatui, which prompts for the new value. The gate reads the file on every request, so no restart is needed.

To add a second person, run the same command with a different username.

To use single sign-on instead, configure OPENID_CLIENT_ID and OPENID_CLIENT_SECRET in /var/lib/chat-ui/.env.local. Keep the gateway credential in place as well, because the preflight guard checks it.

SecureAnyCloud never ships a model provider token. The image is configured for the public Hugging Face Inference Router, whose model list is readable without one. This is why the interface and the model picker work immediately.

To actually send messages, add your own token. The whole configuration surface is one file. Print it with the secrets masked:

sudo grep -vE '^\s*#' /var/lib/chat-ui/.env.local | grep -v '^$' \
  | sed -E 's|^(MONGODB_URL=).*|\1<generated on this VM at first boot>|'

OPENAI_BASE_URL=https://router.huggingface.co/v1 OPENAI_API_KEY= <set-at-first-boot>=<generated on this VM at first boot> MONGODB_DB_NAME=chat-ui COOKIE_SAMESITE=lax COOKIE_SECURE=false PROTOCOL_HEADER=x-forwarded-proto HOST_HEADER=x-forwarded-host TASK_MODEL= OPENID_CLIENT_ID= OPENID_CLIENT_SECRET= <set-at-first-boot>=true ENABLE_DATA_EXPORT=true

Edit that file with your preferred editor as root and set OPENAI_API_KEY to your own token. These are the settings to change:

# Hugging Face Inference Router (the shipped default) OPENAI_BASE_URL=https://router.huggingface.co/v1 OPENAI_API_KEY=<your-token>
# or OpenAI
# OPENAI_BASE_URL=https://api.openai.com/v1
# or your own private endpoint - Ollama, vLLM, TGI, LM Studio
# OPENAI_BASE_URL=http://10.100.1.20:11434/v1
# OPENAI_API_KEY=<set-at-first-boot>

Then restart the service:

sudo systemctl restart chat-ui.service

Chat UI rediscovers the model list from ${OPENAI_BASE_URL}/models on every start, so whatever your endpoint serves is what appears in the picker. The interface shows the configured endpoint under Settings, along with the exact upstream commit this image was built from.

Your token lives only on this VM, and the access gate from Step 7 is what stops anyone else from using it.

Conversation history lives in MongoDB on this VM. MongoDB is published on the loopback address only and is never reachable from the network. Check the listening ports:

sudo ss -lntp | grep -E ':(80|3000|27017) ' | awk '{print $1, $4}'

Only nginx is on a routable address. Chat UI itself and MongoDB are both loopback bound, so every request has to pass the gate:

LISTEN 0.0.0.0:80 LISTEN 127.0.0.1:3000 LISTEN 127.0.0.1:27017 LISTEN [::]:80

Administer the database from the VM. Read the password out of the credentials file so that it never lands in your shell history:

MP=$(sudo grep -m1 '^MONGODB_PASSWORD=' /root/chat-ui-credentials.txt | cut -d= -f2-) sudo docker exec chat-ui-mongo mongosh --quiet \
  -u chatui_admin -p "$MP" --authenticationDatabase admin chat-ui \
  --eval 'print("collections: " + db.getCollectionNames().length)' \
  --eval 'print("conversations: " + db.conversations.countDocuments({}))'

collections: 14 conversations: 0

Back it up with mongodump, writing the archive out of the container:

MP=$(sudo grep -m1 '^MONGODB_PASSWORD=' /root/chat-ui-credentials.txt | cut -d= -f2-) sudo docker exec chat-ui-mongo mongodump --quiet \
  -u chatui_admin -p "$MP" --authenticationDatabase admin \
  --db chat-ui --archive=/tmp/chat-ui-backup.archive sudo docker cp chat-ui-mongo:/tmp/chat-ui-backup.archive /var/backups/chat-ui-backup.archive
sudo ls -lh /var/backups/chat-ui-backup.archive

The data directory itself is /var/lib/chat-ui/mongodb on the OS disk, so an Azure disk snapshot of the VM captures it too.

Check the service status and the recent application logs:

sudo systemctl status chat-ui.service --no-pager | head -8 sudo docker compose -f /var/lib/chat-ui/docker-compose.yml logs --tail 15 chat-ui

Restart the application after any configuration change, and reload the gateway after any nginx change:

sudo systemctl restart chat-ui.service
sudo nginx -t && sudo systemctl reload nginx

Ubuntu security updates are applied automatically by unattended-upgrades, which covers the nginx gateway.

The two container images are pinned by digest and are deliberately not updated automatically. To move to a newer Chat UI release, edit the image: digest in /var/lib/chat-ui/docker-compose.yml, then run sudo systemctl restart chat-ui.service.