OrientDB 3.2 Multi-Model Database on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and operation of OrientDB 3.2 Community Edition on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. OrientDB is a multi-model database: the same engine stores graph data (vertices and edges, traversed natively) and document data (schema-less records with nested embedded documents), and queries both with a single SQL dialect that has graph extensions such as MATCH, TRAVERSE and out() / in() / both(). It ships OrientDB Studio, a browser workbench for schema, queries and graph visualisation. OrientDB is released under the Apache License 2.0.

The image installs the official OrientDB Community server distribution (version 3.2.56 at build time) to /opt/orientdb, running under OpenJDK 21. Both of OrientDB's own listeners, the binary protocol on 2424 and the HTTP/Studio listener on 2480, are bound to loopback only. nginx terminates TLS on port 443 in front of them, so the appliance exposes exactly two ports to the network: 22 (SSH) and 443 (HTTPS). Nothing is served in plaintext, and every path behind the gateway requires authentication.

At first boot, orientdb-firstboot.service generates a unique per VM credential (there is no default login baked into the image), generates a per VM TLS certificate, creates the Demo database with sample graph and document data, proves an authenticated round trip, and writes the credential to /root/orientdb-credentials.txt (mode 0600, root only).

What is included:

• OrientDB 3.2 Community server from Maven Central, version pinned and sha256 verified

• OpenJDK 21 JRE headless. OrientDB 3.2.56 is tested upstream on JDK 11, 17, 19 and 21

• orientdb.service systemd unit running the server as the unprivileged orientdb user

• orientdb-firstboot.service systemd oneshot that mints the per VM credential, the TLS certificate and the Demo database

• nginx on 443 with a per VM certificate, reverse proxying to the loopback bound OrientDB HTTP listener

• OrientDB Studio, the graph and document workbench, at https://<vm-ip>/studio/index.html

• Ubuntu 24.04 LTS base with the latest security patches

• Azure Linux Agent for seamless cloud integration and SSH key injection

• 24/7 cloudimg support with guaranteed 24 hour response SLA

A note on query languages. OrientDB 3.2 Community answers SQL, including its graph extensions. Gremlin and Cypher are not available in this edition at this version; this was measured against the shipped build rather than taken from documentation. Everything in this guide uses SQL.

Prerequisites

• An active Azure subscription, an SSH public key, and a VNet plus subnet in the target region

• A subscription to the OrientDB 3.2 on Ubuntu 24.04 listing on Azure Marketplace

Recommended virtual machine size: Standard_B2ms (2 vCPU, 8 GB RAM). The JVM is configured with a 2 GB maximum heap and uses roughly 230 MB resident at idle with the sample database loaded, so B2ms leaves substantial headroom for real working sets. For production graph workloads use Standard_E4s_v5 (4 vCPU, 32 GB RAM) or larger and raise the heap in /etc/default/orientdb (ORIENTDB_OPTS_MEMORY=-Xms2G -Xmx16G).

Step 1: Deploy from the Azure Portal

Search OrientDB in Marketplace, select the cloudimg publisher entry, then click Create.

Network security group rules: allow TCP 22 from your management IP and TCP 443 from your client IPs. No other port needs to be open, and none other is listening.

Step 2: Deploy from the Azure CLI

RG="orientdb-prod"; LOCATION="eastus"; VM_NAME="orientdb-01"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/orientdb-ubuntu-24-04/versions/<version>"

az group create --name "$RG" --location "$LOCATION"
az network vnet create -g "$RG" --name odb-vnet \
  --address-prefix 10.90.0.0/16 --subnet-name odb-subnet --subnet-prefix 10.90.1.0/24
az network nsg create -g "$RG" --name odb-nsg
az network nsg rule create -g "$RG" --nsg-name odb-nsg --name allow-ssh \
  --priority 100 --destination-port-ranges 22 --access Allow --protocol Tcp \
  --source-address-prefixes "<your-ip>/32"
az network nsg rule create -g "$RG" --nsg-name odb-nsg --name allow-https \
  --priority 110 --destination-port-ranges 443 --access Allow --protocol Tcp \
  --source-address-prefixes "<your-ip>/32"

az vm create -g "$RG" --name "$VM_NAME" --image "$GALLERY_IMAGE_ID" \
  --size Standard_B2ms --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values ~/.ssh/id_rsa.pub \
  --vnet-name odb-vnet --subnet odb-subnet --nsg odb-nsg \
  --public-ip-sku Standard --location "$LOCATION"

Step 3: Connect via SSH

ssh azureuser@<vm-ip>

Step 4: Verify the OrientDB Service

First boot takes roughly 30 to 60 seconds after the VM reports running. Confirm both units are active:

sudo systemctl is-active orientdb.service nginx.service

Expected output:

active
active

You can confirm that first boot genuinely ran on this VM, rather than inheriting state from the image, by checking its sentinel and the log it writes:

test -f /var/lib/cloudimg/orientdb-firstboot.done && echo "first boot completed on this VM"
sudo grep -E 'Generated per-VM|Per-VM TLS|Rotating the built-in|Password stripped' /var/log/cloudimg-firstboot.log

Step 5: Confirm the Java Runtime

java -version 2>&1 | head -1

Expected output:

openjdk version "21.0.12" 2026-07-21

Step 6: Inspect the Listeners

OrientDB's own ports are bound to loopback. Only SSH and HTTPS are reachable from the network:

ss -lntH | awk '{for(i=1;i<=NF;i++) if($i ~ /:[0-9]+$/){print $i; break}}' | sort -u

Expected output:

0.0.0.0:22
0.0.0.0:443
127.0.0.53%lo:53
127.0.0.54:53
[::]:22
[::]:443
[::ffff:127.0.0.1]:2424
[::ffff:127.0.0.1]:2480

2424 is OrientDB's binary protocol and 2480 its HTTP listener; both show a loopback address. 127.0.0.53 and 127.0.0.54 are the systemd resolver, also loopback. The only addresses reachable off the VM are 22 and 443.

An unauthenticated request to the console is refused:

curl -sk -o /dev/null -w 'unauthenticated  -> HTTP %{http_code}\n' https://127.0.0.1/listDatabases

Expected output:

unauthenticated  -> HTTP 401

Step 7: Retrieve the Per-VM Credential

There is no default password in this image. The credential below is generated on your VM at first boot and exists nowhere else:

sudo cat /root/orientdb-credentials.txt

The file is mode 0600 and owned by root. It contains ORIENTDB_ROOT_USER, ORIENTDB_ROOT_PASSWORD, the Studio URL and the name of the sample database. The same single credential is used in two places: the browser's HTTPS prompt, and the OrientDB Studio login.

Keep the password out of your shell history and off process command lines by passing it to curl on standard input, as every example below does.

Step 8: Query the HTTPS Gateway

List the databases through the TLS gateway. -k is needed because the certificate is self-signed per VM:

printf 'user = "root:<ORIENTDB_PASSWORD>"\n' | curl -sk -K - -w '\n' https://127.0.0.1/listDatabases

Expected output:

{"@type":"d","@version":0,"databases":["Demo"]}

Step 9: Traverse the Graph

The Demo database contains four Person vertices joined by four Knows edges. This is a genuine two-hop graph traversal, not a join:

printf 'user = "root:<ORIENTDB_PASSWORD>"\n' | curl -s -K - -X POST --data-binary \
  "MATCH {class: Person, as: a, where: (name = 'Alice')}.out('Knows'){as: b}.out('Knows'){as: c} RETURN a.name, b.name, c.name" \
  http://127.0.0.1:2480/command/Demo/sql | python3 -m json.tool | head -9

Expected output:

{
    "result": [
        {
            "a.name": "Alice",
            "b.name": "Bob",
            "c.name": "Carol"
        }
    ],

The out() graph function walks edges directly:

printf 'user = "root:<ORIENTDB_PASSWORD>"\n' | curl -s -K - -X POST --data-binary \
  "SELECT name, out('Knows').name AS knows FROM Person ORDER BY name" \
  http://127.0.0.1:2480/command/Demo/sql \
  | python3 -c "
import json, sys
for r in json.load(sys.stdin).get('result', []):
    print(r['name'], '->', r['knows'])
"

Expected output:

Alice -> ['Bob']
Bob -> ['Carol']
Carol -> ['Dave']
Dave -> ['Alice']

Step 10: Query the Document Side

The same database also holds schema-less document records with nested embedded documents. No schema was declared for meta, yet its fields are directly queryable:

printf 'user = "root:<ORIENTDB_PASSWORD>"\n' | curl -s -K - -X POST --data-binary \
  "SELECT title, meta.author AS author, meta.priority AS priority, tags FROM Note ORDER BY title" \
  http://127.0.0.1:2480/command/Demo/sql | python3 -m json.tool | head -12

Expected output:

{
    "result": [
        {
            "title": "Release plan",
            "author": "Alice",
            "priority": 1,
            "tags": [
                "graph",
                "document"
            ]
        },

Step 11: Open OrientDB Studio

Browse to https://<vm-ip>/studio/index.html.

Your browser will warn about the certificate, because it is self-signed and generated on your VM. Accept it, or replace the certificate as described in Step 14. The browser then prompts for the HTTPS gateway credential: enter user root and the password from Step 7.

At the Studio login form, choose database Demo, user root, and the same password, then click CONNECT.

Step 12: Explore the Schema

The SCHEMA tab shows the multi-model shape in one view: Person under Vertex Classes, Knows under Edge Classes, and Note under Generic Classes, the schema-less document class.

Step 13: Run a Traversal and Visualise the Graph

On the BROWSE tab, paste the MATCH query from Step 9 and click RUN. The result table shows the traversal path.

On the GRAPH tab, enter SELECT FROM Person and click the play button. Studio renders the vertices and the Knows edges between them.

Step 14: Security Notes

Guessable credentials are refused. OrientDB's historic defaults do not work on this image. The bundled sample database that ships with the upstream distribution, which carries live admin/admin, reader/reader and writer/writer accounts, is removed at build time and never reaches the image. The built-in guest account, which upstream creates with a published fixed password, has its password rotated at first boot. Verify both:

printf 'user = "guest:!!!TheGuestPw123"\n' | curl -s -K - -o /dev/null \
  -w 'published guest default -> HTTP %{http_code}\n' \
  -X POST --data-binary 'SELECT 1' http://127.0.0.1:2480/command/Demo/sql
printf 'user = "admin:admin"\n' | curl -s -K - -o /dev/null \
  -w 'admin/admin             -> HTTP %{http_code}\n' \
  -X POST --data-binary 'SELECT 1' http://127.0.0.1:2480/command/Demo/sql

Expected output:

published guest default -> HTTP 401
admin/admin             -> HTTP 401

The credential is not left in the service environment. First boot hands the password to the server as an environment variable, then removes it once the account has been persisted into OrientDB's own store, and restarts. Confirm nothing remains:

if sudo grep -q '^ORIENTDB_ROOT_PASSWORD=' /etc/default/orientdb; then
  echo "credential still present in the service environment"
else
  echo "no credential in the service environment"
fi

Expected output:

no credential in the service environment

SSH is hardened:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|clientaliveinterval) '

Expected output:

clientaliveinterval 120
permitrootlogin no
passwordauthentication no

Kernel module mitigation. The image ships the Dirty Frag mitigation for CVE-2026-43284 and CVE-2026-43500:

sudo cat /etc/modprobe.d/dirtyfrag.conf

Expected output:

install esp4 /bin/false
install esp6 /bin/false
install ipcomp /bin/false
install ipcomp4 /bin/false
install ipcomp6 /bin/false
install rxrpc /bin/false

If this VM must terminate IPsec, remove the esp4 and esp6 lines and run sudo update-initramfs -u; leave the rest in place.

Recommended hardening:

• Restrict TCP 443 in the NSG to known client IP ranges. Studio is a database administration console.
• Replace the self-signed certificate with one issued for a hostname you control. Put the certificate and key at /etc/ssl/cloudimg-orientdb/server.crt and server.key, keep the key mode 0600 and owned by root, then reload nginx.
• Create per-user OrientDB accounts for day-to-day work and reserve root for administration.
• Take regular backups with /opt/orientdb/bin/backup.sh, and store them off the VM.

Step 15: Managing the Service

sudo systemctl status orientdb.service
sudo systemctl restart orientdb.service
sudo journalctl -u orientdb.service -n 100 --no-pager

Configuration lives in /etc/default/orientdb (JVM heap and paths) and /opt/orientdb/config/orientdb-server-config.xml (listeners). Databases are stored under /var/lib/orientdb/databases.

Step 16: Support and Licensing

OrientDB Community Edition is distributed under the Apache License 2.0. The licence text shipped in the image is at /opt/orientdb/license.txt.

cloudimg packages and supports this image; cloudimg is not affiliated with, and this image is not endorsed by, the OrientDB project or its trademark holders. OrientDB is a trademark of its respective owner and is used here only to identify the software included.

For support, contact cloudimg through the Azure Marketplace listing. Response SLA is 24 hours, 24/7.