eXist-db 6.4

Confirm that both services are active and that the unauthenticated health endpoint answers. Also confirm that the database itself is bound to loopback only:

sudo systemctl is-active existdb.service nginx.service curl -s -o /dev/null -w 'health: HTTP %{http_code}\n' http://127.0.0.1/health curl -s -o /dev/null -w 'redirect: HTTP %{http_code}\n' http://127.0.0.1/ ss -tlnH | awk '{print $4}' | grep -E ':(80|8080)$' | sort

Both units report active. /health returns HTTP 200. nginx serves it directly, so it is a true liveness probe for the public listener and never depends on the database's auth state.

A request to / returns HTTP 302, which redirects to eXist-db's /exist/ context path.

The listener list shows nginx on 0.0.0.0:80 and [::]:80, and eXist-db on [::ffff:127.0.0.1]:8080. The IPv4-mapped form is still loopback, so the database is not reachable from the network.

The administrator password is unique to this VM. First boot writes it to a root-only file:

sudo cat /root/existdb-credentials.txt

The file prints EXISTDB_URL, EXISTDB_ADMIN_USER (admin) and EXISTDB_ADMIN_PASSWORD (the per-VM password). Keep it safe. The password unlocks the Dashboard, the eXide editor, the package manager and the full REST API. No two SecureAnyCloud deployments share this password.

Every command below reads the password straight from that file into a shell variable, so you paste nothing:

PW=$(sudo grep '^EXISTDB_ADMIN_PASSWORD=' /root/existdb-credentials.txt | cut -d= -f2-)
curl -s -u "admin:$PW" -G http://127.0.0.1/exist/rest/db \
  --data-urlencode '_query=system:get-version()' --data-urlencode '_wrap=no'; echo java -version 2>&1 | head -1

The database reports version 6.4.1 and the JVM reports openjdk version "17.0.19".

Run this check on a fresh deployment. A stock eXist-db install fails it. Each probe asks the database to evaluate the trivial XQuery 1 and prints only the HTTP status:

PW=$(sudo grep '^EXISTDB_ADMIN_PASSWORD=' /root/existdb-credentials.txt | cut -d= -f2-) Q() { curl -s -o /dev/null -w '%{http_code}' -u "$1:$2" -G http://127.0.0.1/exist/rest/db \
  --data-urlencode '_query=1' --data-urlencode '_wrap=no'; } printf 'wrong password: HTTP %s\n' "$(Q admin definitely-wrong)" printf 'upstream empty admin: HTTP %s\n' "$(Q admin '')" printf 'upstream guest/guest: HTTP %s\n' "$(Q guest guest)" printf 'per-VM admin password: HTTP %s\n' "$(Q admin "$PW")"

A wrong password, the upstream empty admin password and the upstream guest/guest pair all return HTTP 401. Only the per-VM password returns HTTP 200.

The same holds for the accounts that eXist-db creates for each bundled application package: eXide, monex and packageservice. Their upstream password is the account name. It also holds for the internal SYSTEM and nobody accounts. You can list every account and re-run the probe against any of them:

PW=$(sudo grep '^EXISTDB_ADMIN_PASSWORD=' /root/existdb-credentials.txt | cut -d= -f2-)
curl -s -u "admin:$PW" -G http://127.0.0.1/exist/rest/db \
  --data-urlencode '_query=string-join(sm:list-users(),", ")' --data-urlencode '_wrap=no'; echo

The accounts present are SYSTEM, admin, eXide, guest, monex, nobody, packageservice.

Store an XML document with a REST PUT, then query it with XQuery. The PUT creates collections implicitly:

PW=$(sudo grep '^EXISTDB_ADMIN_PASSWORD=' /root/existdb-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'PUT catalog.xml: HTTP %{http_code}\n' -u "admin:$PW" \
  -X PUT -H 'Content-Type: application/xml' \
  --data-binary '<catalog><book id="b1"><title>Native XML storage</title></book><book id="b2"><title>XQuery in practice</title></book></catalog>' \
  http://127.0.0.1/exist/rest/db/demo/catalog.xml
curl -s -u "admin:$PW" -G http://127.0.0.1/exist/rest/db \
  --data-urlencode "_query=string-join(for \$b in doc('/db/demo/catalog.xml')//book order by \$b/@id return string(\$b/title),' | ')" \
  --data-urlencode '_wrap=no'; echo
curl -s -u "admin:$PW" -G http://127.0.0.1/exist/rest/db \
  --data-urlencode "_query=count(collection('/db/demo')//book)" --data-urlencode '_wrap=no'; echo

The PUT returns HTTP 201. The FLWOR expression returns Native XML storage | XQuery in practice, which reads the titles back in document order straight out of the stored XML.

The collection() count returns 2. It queries across every resource in the collection, not a single document.

Confirm where the database lives, that the image runs with no swap, and which applications first boot deployed:

PW=$(sudo grep '^EXISTDB_ADMIN_PASSWORD=' /root/existdb-credentials.txt | cut -d= -f2-)
df -h /var/lib/existdb | awk 'NR==1 || /\/$/' free -m | head -3 curl -s -u "admin:$PW" -G http://127.0.0.1/exist/rest/db \
  --data-urlencode '_query=string-join(xmldb:get-child-collections("/db/apps"),", ")' --data-urlencode '_wrap=no'; echo

The database directory is /var/lib/existdb. free -m shows the Swap: row at zero across the board. Azure manages swap on the ephemeral resource disk, and a swap file baked into an OS disk fails image certification, so this image ships without one.

The deployed applications are packageservice, dashboard, eXide, doc, fundocs, monex.

Open http://<vm-ip>/ in a browser. The redirect takes you to the eXist-db launcher. It reports the running version and lists the applications that first boot deployed: eXide (the XQuery IDE), eXist-db Documentation, Monex (monitoring) and XQuery Function Documentation.

Select Login at the top right and sign in as admin with the per-VM password from Step 5: you can browse the launcher without signing in, but saving and administration need a login.

Open eXide from the Dashboard. eXide is eXist-db's in-browser XQuery editor. It edits resources stored in the database, runs queries against live data and shows the results underneath. Paste a query and run it with Eval (or Ctrl-Enter):

xquery version "3.1"; for $b in doc('/db/demo/catalog.xml')//book order by $b/@id return <result id="{$b/@id}">{string($b/title)}</result>

The results panel renders the constructed <result> elements for both stored books. The status toast reports Query returned 2 item(s) with the evaluation time. The query ran inside the database against the document stored in Step 7, with no export step.

eXide's directory and outline panes on the left browse the database hierarchy. You can open, edit and save any stored resource in place.

Open Monex from the launcher. It asks you to sign in as a dba user. Enter admin and the per-VM password from Step 5. This sign-in is the most direct proof that the per-VM credential works in a real browser session.

It lands on the monitoring dashboard, which shows active database brokers, uptime, running queries, waiting threads, and a live Java memory chart.

Use the memory panel to confirm the heap. This image caps the JVM heap explicitly at 1 GiB, rather than letting the JVM take a quarter of system memory. Monex therefore reports the maximum as roughly 989 MiB, with only a small fraction in use on an idle instance. Monex also exposes index and profiling views for tuning queries.

The heap is capped explicitly in /etc/existdb.env (-Xms256m -Xmx1024m), rather than left to the JVM's default of a quarter of system memory. eXist-db's own caches are sized to fit inside it (cacheSize="192M" and collectionCache="48M" in /opt/existdb/etc/conf.xml).

For large corpora, raise all three values together, then restart. eXist-db's own guidance is to keep cacheSize at roughly a third of the maximum heap:

sudo sed -i 's/-Xmx1024m/-Xmx3072m/' /etc/existdb.env
sudo sed -i 's/cacheSize="192M"/cacheSize="768M"/' /opt/existdb/etc/conf.xml
sudo systemctl restart existdb.service

Do not add a swap file to make a larger heap fit, because a swap file on the OS disk fails Azure image certification. Move to a larger VM size instead.

The REST interface at /exist/rest/db/... stores and retrieves resources with PUT, GET and DELETE. It evaluates XQuery through the _query parameter, as used throughout this guide.

RESTXQ lets you publish your own HTTP endpoints. Annotate XQuery functions with %rest:GET and %rest:path, store them in the database, and eXist-db serves them under /exist/restxq/.

XML-RPC is available at /exist/xmlrpc for the Java and Python client libraries.

All three interfaces honor the same accounts and permissions, so the per-VM administrator password authenticates every one of them.

eXist-db ships a consistency-checking backup tool that writes a full or incremental backup of the database to a directory. Run it as the existdb user so that the output has the right owner. Then copy the result off the VM, for example to Azure Files, Blob storage or your own backup target.

You can also configure a scheduled backup from the Dashboard's backup application.

sudo -u existdb EXIST_HOME=/opt/existdb /opt/existdb/bin/backup.sh \
  -u admin -p '<new-password>' -b /db -d <backup-dir>

eXist-db logs to /opt/existdb/logs and the service journal:

sudo journalctl -u existdb.service --no-pager | tail -20 sudo journalctl -u exist-db-firstboot.service --no-pager | tail -20 sudo ls -1 /opt/existdb/logs | head

If port 80 refuses connections, check the first-boot journal above. nginx is gated on the marker /var/lib/sac/data/existdb-bootstrap-ready. First boot creates the marker only after the per-VM password is set and every default credential has been proven rejected. This is deliberate, so the listener never opens onto an unconfigured database.

If first boot failed, the journal names the failing step. nginx stays down until first boot succeeds.

existdb.service reads its environment from /etc/existdb.env, and its main configuration is /opt/existdb/etc/conf.xml. The Jetty connector configuration is under /opt/existdb/etc/jetty/. This image disables the HTTPS connector and removes the distribution's bundled keystore, because TLS terminates at nginx or upstream.