LightRAG

• In the Azure Portal, search the Marketplace for LightRAG by SecureAnyCloud and select Create.
• Choose your subscription, resource group and region, and set the VM name.
• Select size Standard_B2ms and authentication type SSH public key, then paste your key.
• Under Inbound port rules, allow SSH (22) and HTTP (80). Restrict the source of port 80 to your own network, as described in Security hardening below.
• Leave the OS disk defaults, then select Review + create.

Replace the example values with your own. This block is an example and is not run as part of the walkthrough.

az vm image terms accept --urn sac1647283583153:lightrag-ubuntu-24-04:default:latest
az vm create \
  --resource-group my-resource-group \
  --name my-lightrag-vm \
  --image sac1647283583153:lightrag-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard \
  --os-disk-delete-option Delete --nic-delete-option Delete

Then open port 80 to your own network only:

az network nsg rule create \
  --resource-group my-resource-group \
  --nsg-name my-lightrag-vmNSG \
  --name allow-http-from-office \
  --priority 1010 --access Allow --protocol Tcp \
  --destination-port-ranges 80 --source-address-prefixes 203.0.113.0/24

ssh azureuser@<vm-ip>

Four units make up the appliance: docker, lightrag-firstboot (which generates this VM's secrets and proves the gate on the very first boot), lightrag (the application container) and nginx (the access gateway).

sudo systemctl is-active docker.service lightrag-firstboot.service lightrag.service nginx.service

Expected output:

active active active active

The application container itself is pinned by digest and published on the loopback address only:

sudo docker compose -f /var/lib/lightrag/docker-compose.yml ps

Confirm the exact image this VM is running, and that it is the MIT licensed upstream release:

sudo docker image inspect $(sudo docker ps --format '{{.Image}}' | head -1) --format 'licence={{index .Config.Labels "org.opencontainers.image.licenses"}} version={{index .Config.Labels "org.opencontainers.image.version"}} source={{index .Config.Labels "org.opencontainers.image.source"}}'

Expected output:

licence=MIT version=v1.5.4 source=https://github.com/HKUDS/LightRAG

The licences of every Python dependency inside that image were scanned at build time, and the inventory ships with the appliance:

sudo head -n 3 /usr/share/lightrag/dependency-licences.txt

Every VM generates its own credentials on first boot. Nothing is shared between instances and nothing is baked into the image.

sudo cat /root/lightrag-credentials.txt

The file gives you three values:

• LIGHTRAG_USERNAME: the account name for both the gateway and LightRAG's own sign-in.
• LIGHTRAG_PASSWORD: the 32-character password for both.
• LIGHTRAG_APIKEY: a 32-character key for scripts. Sent as the X-API-Key header, it satisfies both layers in one header.

Browse to http://<vm-ip>/.

Your browser asks for a username and password first. This is the gateway, and it stops anyone who finds the address from spending your model provider credit. Enter the username and password from Step 5. The gateway then sets a cookie, so it asks only once.

LightRAG's own sign-in page appears next. Enter the same username and password.

After you sign in, you land on Document Management, which lists everything you have ingested and its indexing status.

LightRAG's own account authentication is optional upstream, and it fails open: with no accounts configured, the server accepts every request. Its default path whitelist also exempts /api/generate and /api/chat, the two routes that actually spend your model provider credit. This image closes both gaps.

Layer one: the gateway. nginx owns port 80 and denies by default. It accepts a request only if the request carries this VM's gate cookie, this VM's API key or this VM's HTTP Basic credential. Prove that it refuses an anonymous caller:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/

Expected output:

401

The gateway refuses the routes that would spend your credit in the same way:

curl -s -o /dev/null -w '%{http_code}\n' -X POST -H 'Content-Type: application/json' -d '{}' http://127.0.0.1/api/chat

Expected output:

401

A wrong password is refused too, not only a missing one:

curl -s -o /dev/null -w '%{http_code}\n' -u '<LIGHTRAG_USERNAME>:definitely-not-the-password' http://127.0.0.1/

Expected output:

401

Layer two: LightRAG's own accounts. Getting past the gateway is not enough. An application route still needs an application credential:

curl -s -o /dev/null -w '%{http_code}\n' -u '<LIGHTRAG_USERNAME>:<LIGHTRAG_PASSWORD>' http://127.0.0.1/documents/pipeline_status

Expected output:

401

The API key satisfies both layers in a single header, so use it from scripts:

curl -s -H 'X-API-Key: <LIGHTRAG_APIKEY>' http://127.0.0.1/graph/label/list

The gateway cannot run ungated. nginx.service carries two ConditionPathExists directives: this VM's credential file, and a marker that first boot writes only after it has proved, against a throwaway internal listener, that the gate answers an unauthenticated request with 401. If that proof fails, first boot tears the stack down and deletes both files, so nginx can never start. Show both conditions:

sudo systemctl cat nginx.service | grep ConditionPathExists

The application is never reachable directly. It is published on the loopback address only, so every request must pass the gateway:

sudo ss -lntH | awk '{print $4}' | sort -u

LightRAG does not host a model. Until you give it a provider, it can serve the interface but cannot index a document or answer a question.

The configuration file is /var/lib/lightrag/lightrag.env. It ships pre-filled for OpenAI with both keys empty:

sudo grep -E '^(LLM_BINDING|LLM_MODEL|EMBEDDING_BINDING|EMBEDDING_MODEL|EMBEDDING_DIM)=' /var/lib/lightrag/lightrag.env

Edit the file and set your own keys. You perform this step yourself; it is not run as part of the walkthrough:

sudo nano /var/lib/lightrag/lightrag.env

Set LLM_BINDING_API_KEY= and EMBEDDING_BINDING_API_KEY= to your own key, then restart and wait for the service to come back:

sudo systemctl restart lightrag.service for i in $(seq 1 30); do [ "$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 -H 'X-API-Key: <LIGHTRAG_APIKEY>' http://127.0.0.1/health)" = "200" ] && break sleep 2 done
sudo systemctl is-active lightrag.service

The file carries commented blocks for the common alternatives:

• Azure OpenAI. Set LLM_BINDING=azure_openai and LLM_BINDING_HOST=https://<your-resource>.openai.azure.com/, and use your deployment names for LLM_MODEL and EMBEDDING_MODEL.
• Ollama on this VM or your network. Set LLM_BINDING=ollama and LLM_BINDING_HOST=http://host.docker.internal:11434. The container is already configured to reach the VM's own host address.
• Any OpenAI-compatible server (vLLM, LM Studio, TGI, OpenRouter, Together). Keep LLM_BINDING=openai and point LLM_BINDING_HOST at its /v1 URL.

Your key stays on this VM. SecureAnyCloud never ships a model provider credential, and the image is built and tested with both key fields empty.

Upload through the web interface with Documents > Upload, or over the API. Indexing is asynchronous. LightRAG chunks the document, asks your model to extract entities and relationships, embeds the passages and merges the result into the knowledge graph.

Watch the pipeline:

curl -s -H 'X-API-Key: <LIGHTRAG_APIKEY>' http://127.0.0.1/documents/pipeline_status | head -c 300

List the entities currently in the knowledge graph:

curl -s -H 'X-API-Key: <LIGHTRAG_APIKEY>' http://127.0.0.1/graph/label/list

The Knowledge Graph tab draws what was extracted. Entities are nodes, and the relationships your model found between them are edges. Click any node to inspect or edit its description.

Ask a question from the Retrieval tab, or over the API. The mode setting selects how much of the graph is used: naive is plain vector search, local and global walk the graph from different directions, hybrid combines them and mix uses everything.

LightRAG refuses to ingest the same file name twice. To re-index a changed document, delete the existing record first.

Storage is file-based by design. There is no database server on this instance, so there is nothing extra to secure, patch or licence.

sudo ls -la /var/lib/lightrag/data/rag_storage/

• graph_*.graphml: the entity and relationship graph, stored with NetworkX (BSD-3-Clause).
• vdb_*.json: the vector indexes for entities, relations and chunks, stored with NanoVectorDB (MIT).
• kv_store_*.json: documents, chunk text and indexing status, stored in the JSON key/value store.

Your uploaded originals live alongside them in /var/lib/lightrag/data/inputs. Both directories are 0700 root:root. The gateway serves no file from disk at all and only proxies to the application, so nothing you ingest is reachable over HTTP except through LightRAG's own authenticated API.

sudo stat -c '%n %a %U:%G' /var/lib/lightrag/data /var/lib/lightrag/data/inputs /var/lib/lightrag/data/rag_storage

Expected output:

/var/lib/lightrag/data 700 root:root /var/lib/lightrag/data/inputs 700 root:root /var/lib/lightrag/data/rag_storage 700 root:root

Back up that one directory to back up your entire knowledge base:

sudo tar czf /var/backups/lightrag-kb-$(date +%Y%m%d).tar.gz -C /var/lib/lightrag data

sudo systemctl restart lightrag.service

sudo docker compose -f /var/lib/lightrag/docker-compose.yml logs --tail 20

Configuration changes always need a service restart, because the file is mounted read-only into the container.