YugabyteDB 2025.2.8.0 LTS on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers deploying and using YugabyteDB 2025.2.8.0 on Ubuntu 24.04 LTS from cloudimg on Microsoft Azure.

YugabyteDB is an open source distributed SQL database. It stores data in DocDB, a replicated, sharded document store, and puts two APIs on top of it: YSQL, which is PostgreSQL compatible (it reuses the PostgreSQL 15 query layer, so psql, PostgreSQL drivers and most PostgreSQL SQL work unchanged), and YCQL, which is compatible with Apache Cassandra's query language. Tables are split into tablets automatically; on a multi-node cluster the tablets are replicated and spread across nodes so the database keeps serving through node failures. This image runs a single-node cluster, which is the right start for development, testing and small production workloads, and the base you grow from.

The version is 2025.2.8.0 from the v2025.2 LTS (long-term support) series, released 23 October 2026 and maintained by Yugabyte until December 2027. cloudimg chose it over the newer v2026.1 STS (standard-term support) series because the latest STS build does not yet carry the upstream PostgreSQL 15.19 security fixes that this LTS build includes.

What the cloudimg image adds:

• No default login, passwords unique to your VM. Upstream YugabyteDB starts with authentication off and with the superusers yugabyte/yugabyte (YSQL) and cassandra/cassandra (YCQL). Here password authentication is on for both APIs, and the image ships no database at all: first boot creates the cluster inside a private network namespace that nothing else on the VM can reach, changes both superuser passwords to 32 character values generated on your VM, proves the upstream defaults are refused, and only then lets the database services start. The passwords are written to the root only file /root/yugabytedb-credentials.txt, never to a command line, a log or the journal.
• Everything on localhost. Every YugabyteDB port listens on 127.0.0.1 only: YSQL (5433), YCQL (9042), the internal RPC ports (7100, 9100) and the web consoles (7000, 9000, 13000, 12000). From the network, only SSH (22) is reachable; you connect through an SSH tunnel (Step 9), or open YSQL or YCQL to your own network when you choose to (Step 10).
• TLS everywhere, with a certificate authority of your own. First boot creates a certificate authority and a server certificate unique to your VM. Client connections (YSQL and YCQL) and the traffic between YugabyteDB's own servers are encrypted with it, and unencrypted connections are refused. YSQL accepts only TLS connections with SCRAM-SHA-256 passwords.
• No call home. YugabyteDB's diagnostics reporting (callhome) is switched off on both servers; the build proves that the database makes no outbound connection.
• Hardened services. yb-master and yb-tserver run as the unprivileged yugabyte user with no capabilities, a read-only view of the system and no access to /root or the Azure agent's files. They and the first boot service are blocked from the Azure Instance Metadata Service and the WireServer (YSQL can connect to addresses a SQL user names, for example with postgres_fdw or dblink), while the Azure Linux Agent and cloud-init keep their access. fwupd's automatic firmware-metadata refresh is switched off (Azure VMs have no firmware it can update).
• Your data on its own disk. The cluster's data, write-ahead logs and server logs (/var/lib/yugabyte) are on a dedicated 40 GiB Azure data disk you can grow or snapshot on its own.
• Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on. YugabyteDB is the vendor's Apache-2.0 release tarball, its checksum verified at build time.

What is on the image: YugabyteDB 2025.2.8.0 in /opt/yugabyte (yb-master, yb-tserver, the ysqlsh and ycqlsh shells, yb-admin, ysql_dump), the helpers yb-ysqlsh, yb-ycqlsh and yb-ysql-dump that sign you in, Ubuntu 24.04 LTS, cloud-init and the Azure Linux Agent. The yugabyte database is empty, ready for your tables; there is no sample database or keyspace.

Default user: the administrator you choose at deployment (azureuser in the examples) · Architecture: x64, Gen2 · Recommended size: Standard_B4ms (4 vCPU, 16 GiB)

What this image leaves out, and why

cloudimg removed five parts of the vendor tarball. None is needed to run the database:

Left out	Why
YB Controller (share/ybc-*.tar.gz, the YBC backup daemon)	It is licensed under the PolyForm Free Trial licence, which does not allow redistribution; the rest of the tarball is Apache-2.0. Backups on this image use yb-admin snapshots and ysql_dump (Step 13), not YBC.
yugabyted and yugabyted-ui	The image runs yb-master and yb-tserver directly as systemd services (YugabyteDB's manual deployment model), so the yugabyted launcher and its web UI are not used. yugabyted-ui is built with Go 1.26.6 and govulncheck reports 13 reachable Go standard library advisories in it that are fixed in later Go releases. The master and tablet server consoles (Step 9) remain.
pg_parquet (the YSQL extension)	It is built in Rust and cargo-audit reports 22 advisories in the libraries it bundles (among them rustls 0.21, rustls-webpki 0.101, h2, quick-xml and lz4_flex), with no fixed build yet.
redis-cli	It is the client from Redis 4.0.1 with hiredis 0.13.3, which have known client-side advisories; YugabyteDB's Redis-compatible API (YEDIS) is off on this image.
python/ai (an example RAG agent)	It is not installed or started by anything, and its requirements pin packages with known advisories (fastapi 0.104.1, python-multipart 0.0.6, python-jose 3.3.0).

What this is not

This is a single-node cluster (replication factor 1): it does not replicate data to other machines, so protect it with disk snapshots and backups (Step 13). Growing to a multi-node, fault-tolerant cluster means adding VMs, binding the RPC ports to the private network and raising the replication factor; see YugabyteDB's manual deployment documentation. YugabyteDB Anywhere (Yugabyte's commercial cluster manager) is not part of this image. Earlier versions of this image published a web dashboard on port 80; this version does not: the consoles are reached through SSH (Step 9).

Prerequisites

• An Azure subscription, an SSH key pair, and a virtual network and subnet in your region.
• A network security group (NSG) that allows TCP 22 (SSH) from your admin network. YugabyteDB listens on the loopback address only, so no database port needs to be open; you reach it through an SSH tunnel (Step 9).

Step 1: Deploy from the Azure Marketplace

Sign in to the Azure portal, choose Create a resource, search the Marketplace for YugabyteDB by cloudimg and select Create. On Basics pick your subscription, resource group, region and size (Standard_B4ms or larger: YugabyteDB needs at least 8 GiB of memory; give it more for larger working sets). Under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) only. The Disks tab shows the image's 40 GiB data disk (LUN 0) for /var/lib/yugabyte; make it as large as your data needs. Then Review + create, Create. First boot takes about a minute once the VM is running.

Step 2: Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deployment)
az vm image terms accept --urn cloudimg1647283583153:yugabytedb-ubuntu-24-04:default:latest

az vm create \
  --resource-group <your-rg> \
  --name yugabytedb \
  --image cloudimg1647283583153:yugabytedb-ubuntu-24-04:default:latest \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm create opens SSH (22) and nothing else. To make the data disk larger, resize it while the VM is deallocated, then grow the file system once it is running again:

az vm deallocate --resource-group <your-rg> --name yugabytedb
az disk update --resource-group <your-rg> --name <data-disk-name> --size-gb 200
az vm start --resource-group <your-rg> --name yugabytedb
sudo resize2fs "$(findmnt -no SOURCE /var/lib/yugabyte)"

Step 3: Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4: Check the services

The address lookup, the first boot service, the master and the tablet server should all be active:

systemctl is-active yugabytedb-address.service yugabytedb-firstboot.service yb-master.service yb-tserver.service

active
active
active
active

Every YugabyteDB port listens on the loopback address; from the network, only SSH is reachable:

sudo ss -Htln | awk '{print $4}' | sort -V

0.0.0.0:22
127.0.0.1:5433
127.0.0.1:7000
127.0.0.1:7100
127.0.0.1:9000
127.0.0.1:9042
127.0.0.1:9100
127.0.0.1:12000
127.0.0.1:13000
127.0.0.53%lo:53
127.0.0.54:53
[::]:22

5433 is YSQL, 9042 is YCQL, 7100 and 9100 are the master's and tablet server's RPC ports, 7000 and 9000 their web consoles, and 13000 and 12000 the YSQL and YCQL metrics consoles. The port 53 lines are Ubuntu's local DNS resolver, also loopback only. yb-admin (which connects over TLS with the VM's certificates) shows the master as the cluster's leader:

sudo -u yugabyte /opt/yugabyte/bin/yb-admin --master_addresses 127.0.0.1:7100 --certs_dir_name /etc/yugabyte/tls list_all_masters

Master UUID                         RPC Host/Port           State       Role    Broadcast Host/Port 
31f106e98b66484285455adf751ee3e9    127.0.0.1:7100          ALIVE       LEADER  127.0.0.1:7100      

The cluster lives on the dedicated data disk:

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINTS /dev/disk/azure/scsi1/lun0

NAME SIZE FSTYPE LABEL         MOUNTPOINTS
sdc   40G ext4   yugabyte-data /var/lib/yugabyte

(The device name, sda, sdb or sdc, depends on the VM; /dev/disk/azure/scsi1/lun0 always points at the data disk.)

Step 5: Get your connection details

Your connection details are in /root/yugabytedb-credentials.txt:

sudo grep -E '^YUGABYTEDB_(VERSION|YSQL_HOST|YSQL_PORT|YSQL_USER|YSQL_DATABASE|YCQL_PORT|YCQL_USER|TLS_CA)=' /root/yugabytedb-credentials.txt

YUGABYTEDB_VERSION=2025.2.8.0-b60
YUGABYTEDB_YSQL_HOST=127.0.0.1
YUGABYTEDB_YSQL_PORT=5433
YUGABYTEDB_YSQL_USER=yugabyte
YUGABYTEDB_YSQL_DATABASE=yugabyte
YUGABYTEDB_YCQL_PORT=9042
YUGABYTEDB_YCQL_USER=cassandra
YUGABYTEDB_TLS_CA=/etc/yugabyte/tls/ca.crt

Show a password itself when you need it (for a client on your own computer):

sudo grep -E '^YUGABYTEDB_(YSQL|YCQL)_PASSWORD=' /root/yugabytedb-credentials.txt

yugabyte is the YSQL superuser and cassandra the YCQL superuser. YUGABYTEDB_TLS_CA_SHA256 in the same file is the SHA-256 fingerprint of this VM's certificate authority, and YUGABYTEDB_TLS_CERT_NAMES lists the names its server certificate carries (127.0.0.1, localhost, the VM's private address, its public address when Azure reports one, and its name). Clients trust the database by its certificate /etc/yugabyte/tls/ca.crt; check the fingerprint:

sudo openssl x509 -in /etc/yugabyte/tls/ca.crt -outform DER | sha256sum | awk '{print $1}'

<YUGABYTEDB_TLS_CA_SHA256>

Step 6: Use YSQL (PostgreSQL compatible)

yb-ysqlsh runs ysqlsh (YugabyteDB's psql) as yugabyte against 127.0.0.1:5433, verifying the server's certificate, with the password handed over in a temporary root-only file:

sudo yb-ysqlsh -c 'SELECT version();'
sudo yb-ysqlsh -c 'SELECT ssl, version, cipher FROM pg_stat_ssl WHERE pid = pg_backend_pid();'

                                                                                          version
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 PostgreSQL 15.12-YB-2025.2.8.0-b0 on x86_64-pc-linux-gnu, compiled by clang version 19.1.0 (https://github.com/yugabyte/llvm-project.git a2a6b655e14e7fa1fcf1011a6cb29cb8575249c0), 64-bit
(1 row)

 ssl | version |         cipher
-----+---------+------------------------
 t   | TLSv1.3 | TLS_AES_256_GCM_SHA384
(1 row)

Create a table split into three tablets, load rows and run an aggregation with a window function:

sudo yb-ysqlsh -c "CREATE TABLE IF NOT EXISTS orders (id bigint PRIMARY KEY, region text NOT NULL, amount numeric(10,2) NOT NULL) SPLIT INTO 3 TABLETS;"
sudo yb-ysqlsh -c "INSERT INTO orders SELECT g, (ARRAY['EMEA','APAC','AMER'])[1 + g % 3], round((g * 7.31)::numeric % 500, 2) FROM generate_series(1, 3000) AS g ON CONFLICT (id) DO NOTHING;"
sudo yb-ysqlsh -c "SELECT region, count(*) AS orders, sum(amount) AS revenue, rank() OVER (ORDER BY sum(amount) DESC) AS rank FROM orders GROUP BY region ORDER BY rank;"
sudo yb-ysqlsh -c "SELECT num_tablets, num_hash_key_columns FROM yb_table_properties('orders'::regclass);"

CREATE TABLE
INSERT 0 3000
 region | orders |  revenue  | rank
--------+--------+-----------+------
 APAC   |   1000 | 250345.00 |    1
 AMER   |   1000 | 248655.00 |    2
 EMEA   |   1000 | 247465.00 |    3
(3 rows)

 num_tablets | num_hash_key_columns
-------------+----------------------
           3 |                    1
(1 row)

Run sudo yb-ysqlsh with no options for an interactive session (\q quits). For applications, create a dedicated role rather than using yugabyte: in an interactive session run CREATE ROLE app LOGIN; then \password app (the password is typed at a prompt and sent to the server already hashed), followed by the GRANT statements your application needs.

Step 7: Use YCQL (Cassandra compatible)

yb-ycqlsh runs ycqlsh as cassandra against 127.0.0.1:9042 over verified TLS, with the password handed over in a temporary root-only file:

sudo yb-ycqlsh -e "CREATE KEYSPACE IF NOT EXISTS shop; CREATE TABLE IF NOT EXISTS shop.carts (user_id int, item text, qty int, PRIMARY KEY ((user_id), item)); INSERT INTO shop.carts (user_id, item, qty) VALUES (1, 'keyboard', 1); INSERT INTO shop.carts (user_id, item, qty) VALUES (1, 'mouse', 2);"
sudo yb-ycqlsh -e "SELECT * FROM shop.carts WHERE user_id = 1;"

 user_id | item     | qty
---------+----------+-----
       1 | keyboard |   1
       1 |    mouse |   2

(2 rows)

For applications, create a dedicated role in an interactive sudo yb-ycqlsh session (CREATE ROLE app WITH PASSWORD = '<password>' AND LOGIN = true;, typed at the prompt, not on a command line) and GRANT it the keyspaces it needs.

Step 8: Remove the examples

sudo yb-ysqlsh -c "DROP TABLE IF EXISTS orders;"
sudo yb-ycqlsh -e "DROP TABLE IF EXISTS shop.carts; DROP KEYSPACE IF EXISTS shop;"

DROP TABLE

Step 9: Connect from your own computer through an SSH tunnel

Every port listens on 127.0.0.1. Forward the ones you need over SSH from your computer:

ssh -N -L 5433:127.0.0.1:5433 -L 9042:127.0.0.1:9042 -L 7000:127.0.0.1:7000 -L 9000:127.0.0.1:9000 azureuser@<vm-public-ip>

Copy the VM's certificate authority to your computer once (scp azureuser@<vm-public-ip>:/etc/yugabyte/tls/ca.crt yugabytedb-ca.crt), then connect with any PostgreSQL client or driver, or with cqlsh/ycqlsh and the Cassandra drivers:

psql "host=127.0.0.1 port=5433 user=yugabyte dbname=yugabyte sslmode=verify-full sslrootcert=yugabytedb-ca.crt"
SSL_CERTFILE=yugabytedb-ca.crt ycqlsh --ssl -u cassandra 127.0.0.1 9042

Enter the passwords from Step 5 when prompted. The certificate names 127.0.0.1, so sslmode=verify-full works through the tunnel.

The web consoles are YugabyteDB's master console at http://127.0.0.1:7000/ (cluster overview, tablet servers, tables and tablets) and the tablet server console at http://127.0.0.1:9000/. The web consoles (ports 7000, 9000, 12000 and 13000) have no login of their own, so anyone with a shell on the VM can read them. That is why they listen on localhost only: open them through the SSH tunnel above, never expose ports 7000, 9000, 12000 or 13000 to a network, and give shell access to the VM only to people you would trust with the database.

The Tablet Servers page lists the VM's tablet server 127.0.0.1:9000 as ALIVE, with its tablet peers and leaders:

The Tables page shows each YSQL and YCQL table with its on-disk size, here the orders table from Step 6 (database yugabyte) and the carts table from Step 7 (keyspace shop):

The tablet server console on port 9000 lists the tablets the server hosts, with their tables, hash partitions, state, Raft roles and on-disk sizes (scroll right for the last two):

Step 10: Optional: open YSQL or YCQL to your own network

If applications in your virtual network must connect without SSH, bind the client ports to all interfaces. TLS and password authentication stay enforced: YSQL accepts only TLS connections with SCRAM passwords and refuses plaintext, and YCQL refuses unencrypted connections. Edit /etc/yugabyte/tserver.conf:

sudo sed -i 's#^--pgsql_proxy_bind_address=127.0.0.1:5433$#--pgsql_proxy_bind_address=0.0.0.0:5433#' /etc/yugabyte/tserver.conf
sudo sed -i 's#^--cql_proxy_bind_address=127.0.0.1:9042$#--cql_proxy_bind_address=0.0.0.0:9042#' /etc/yugabyte/tserver.conf
sudo systemctl restart yb-tserver.service

Then allow TCP 5433 (and 9042 for YCQL) in the VM's NSG from your own network only (never * or Internet):

az network nsg rule create --resource-group <your-rg> --nsg-name <your-nsg> \
  --name allow-ysql-from-office --priority 1010 --direction Inbound --access Allow \
  --protocol Tcp --destination-port-ranges 5433 --source-address-prefixes <your-cidr>

Clients in your virtual network connect to the VM's private address with the certificate authority from Step 9, for example psql "host=<vm-private-ip> port=5433 user=yugabyte dbname=yugabyte sslmode=verify-full sslrootcert=yugabytedb-ca.crt". The certificate names only the addresses in YUGABYTEDB_TLS_CERT_NAMES (Step 5), which the VM had at first boot; a dynamic public IP changes when the VM is deallocated, so use sslmode=verify-ca if you connect by an address or name the certificate does not carry. Keep the RPC ports (7100, 9100) and the consoles on localhost unless you are building a multi-node cluster. To close access again, put the two lines back to 127.0.0.1, restart yb-tserver and delete the NSG rule.

Step 11: Security checks

YugabyteDB and its first boot service cannot reach the Azure Instance Metadata Service (169.254.169.254) or the WireServer (168.63.129.16); systemd lists the blocked addresses in no fixed order, so they are sorted here:

for u in yb-master yb-tserver yugabytedb-firstboot; do printf '%s: ' "$u"; systemctl show -p IPAddressDeny --value "$u.service" | tr ' ' '\n' | sort | tr '\n' ' '; echo; done

yb-master: 168.63.129.16/32 169.254.169.254/32 ::ffff:168.63.129.16/128 ::ffff:169.254.169.254/128 fd00:ec2::254/128 
yb-tserver: 168.63.129.16/32 169.254.169.254/32 ::ffff:168.63.129.16/128 ::ffff:169.254.169.254/128 fd00:ec2::254/128 
yugabytedb-firstboot: 168.63.129.16/32 169.254.169.254/32 ::ffff:168.63.129.16/128 ::ffff:169.254.169.254/128 fd00:ec2::254/128 

The image's own probe proves it from inside the tablet server's control group, with a loopback connection as the control (the Azure Linux Agent is not blocked, so the VM itself keeps working with Azure):

sudo bash -c 'echo $$ > /sys/fs/cgroup$(systemctl show -p ControlGroup --value yb-tserver.service)/cgroup.procs; exec setpriv --reuid=yugabyte --regid=yugabyte --init-groups /usr/local/sbin/cloudimg-egress-probe yb-tserver.service'

EGRESS-PROBE yb-tserver.service loopback=REACHABLE imds4=TimeoutError imds4mapped=TimeoutError imds6=ENETUNREACH wireserver=TimeoutError wireservermapped=TimeoutError verdict=BLOCKED

The tablet server's effective settings: authentication on for both APIs, TLS between clients and servers and between the servers, unencrypted connections refused, call home off, and the client ports on localhost:

curl -s 'http://127.0.0.1:9000/varz?raw=1' | grep -E '^--(callhome_enabled|ysql_enable_auth|use_cassandra_authentication|use_client_to_server_encryption|use_node_to_node_encryption|allow_insecure_connections|pgsql_proxy_bind_address|cql_proxy_bind_address)='

--allow_insecure_connections=false
--callhome_enabled=false
--cql_proxy_bind_address=127.0.0.1:9042
--pgsql_proxy_bind_address=127.0.0.1:5433
--use_cassandra_authentication=true
--use_client_to_server_encryption=true
--use_node_to_node_encryption=true
--ysql_enable_auth=true

YugabyteDB runs unprivileged:

ps -o user:9=,comm= -u yugabyte | sort | uniq -c
sudo grep -E '^(CapEff|NoNewPrivs)' /proc/$(systemctl show -p MainPID --value yb-tserver.service)/status

      5 yugabyte  postgres
      1 yugabyte  yb-master
      1 yugabyte  yb-tserver
CapEff: 0000000000000000
NoNewPrivs: 1

The image's own round trip: the per-VM passwords work over verified TLS and an analytic query returns exact results, while yugabyte/yugabyte, cassandra/cassandra, the password-less postgres role, anonymous YCQL, blank, common and random passwords and plaintext connections are refused; it also checks that every port is loopback only:

sudo /usr/local/sbin/yugabytedb-roundtrip.sh | tail -1

OK-yugabytedb-roundtrip

Step 12: Change the passwords

Change a password without putting it on a command line. Open a root shell, type the new password at a hidden prompt (read is a shell built-in, so the value never appears in the process list), hand the statement to the database on standard input, then write it into the credentials file with shell built-ins so yb-ysqlsh keeps working:

sudo -i
read -rs -p 'New YSQL password: ' NEWPW; echo
printf "ALTER ROLE yugabyte WITH PASSWORD '%s';\n" "$NEWPW" | yb-ysqlsh -q -f -
C=/root/yugabytedb-credentials.txt
while IFS= read -r l; do case "$l" in YUGABYTEDB_YSQL_PASSWORD=*) printf 'YUGABYTEDB_YSQL_PASSWORD=%s\n' "$NEWPW" ;; *) printf '%s\n' "$l" ;; esac; done < "$C" > "$C.new" && chmod 600 "$C.new" && mv "$C.new" "$C"
unset NEWPW; yb-ysqlsh -c 'SELECT 1;' && exit

For YCQL, the statement goes in a temporary root-only file that ycqlsh reads:

sudo -i
read -rs -p 'New YCQL password: ' NEWPW; echo
T=$(mktemp /run/ycql.XXXXXX); printf "ALTER ROLE cassandra WITH PASSWORD = '%s';\n" "$NEWPW" > "$T"; yb-ycqlsh -f "$T"; shred -u "$T"
C=/root/yugabytedb-credentials.txt
while IFS= read -r l; do case "$l" in YUGABYTEDB_YCQL_PASSWORD=*) printf 'YUGABYTEDB_YCQL_PASSWORD=%s\n' "$NEWPW" ;; *) printf '%s\n' "$l" ;; esac; done < "$C" > "$C.new" && chmod 600 "$C.new" && mv "$C.new" "$C"
unset NEWPW; yb-ycqlsh -e 'SELECT release_version FROM system.local;' && exit

Use letters and digits (a quote character would end the SQL string). The round trip (Step 11) expects 32 character passwords; it keeps passing until you change them, and the database itself accepts any length.

Step 13: Backup, updates and maintenance

• Back up with Azure snapshots of the data disk (consistent when you stop yb-tserver and yb-master first), with a logical YSQL dump, or with YugabyteDB's own distributed snapshots. This image does not include the YB Controller backup daemon (see "What this image leaves out"); yb-admin and ysql_dump are the backup tools. A schema and data dump of the yugabyte database to a root only file: sudo yb-ysql-dump > /root/yugabyte-$(date +%F).sql. A distributed snapshot, kept on the data disk:

sudo -u yugabyte /opt/yugabyte/bin/yb-admin --master_addresses 127.0.0.1:7100 --certs_dir_name /etc/yugabyte/tls create_database_snapshot ysql.yugabyte
sudo -u yugabyte /opt/yugabyte/bin/yb-admin --master_addresses 127.0.0.1:7100 --certs_dir_name /etc/yugabyte/tls list_snapshots

An Azure snapshot of the data disk:

az snapshot create --resource-group <your-rg> --name yugabytedb-data-$(date +%F) --source <data-disk-name>

• Memory: YugabyteDB sizes its caches from the VM's memory at start (--use_memory_defaults_optimized_for_ysql); choose a larger VM size for larger working sets and restart both services after resizing.
• Logs: sudo journalctl -u yb-tserver.service -n 50, and the server logs in /var/lib/yugabyte/logs/master and /var/lib/yugabyte/logs/tserver.
• Configuration: the servers read their flags from /etc/yugabyte/master.conf and /etc/yugabyte/tserver.conf; restart the service after a change. Keep --callhome_enabled=false, --allow_insecure_connections=false and the authentication flags as they are.
• Certificates: the certificate authority's key /etc/yugabyte/tls/ca.key stays on the VM (root only) so you can sign certificates for more nodes; the servers use node.127.0.0.1.crt and node.127.0.0.1.key.
• A data disk the VM did not create: first boot refuses to touch a data disk that already holds data it did not create (for example one restored from a snapshot of another VM), and the database services stay stopped until first boot has finished; the reason is in journalctl -u yugabytedb-firstboot.service.
• Updates: Ubuntu security updates install automatically. YugabyteDB is installed from the vendor's tarball in /opt/yugabyte; upgrade it deliberately by following YugabyteDB's manual upgrade procedure after taking a snapshot of the data disk, and keep to the v2025.2 LTS series for long-term support.

Support and licensing

YugabyteDB is open source software under the Apache License 2.0; the build on this image is the vendor's unmodified Apache-2.0 release with the five parts listed above removed (/usr/share/cloudimg/yugabytedb/LICENSE-NOTE.txt). cloudimg provides 24/7 technical support for this image by email and live chat: support@cloudimg.co.uk. YugabyteDB is a trademark of YugabyteDB, Inc.; PostgreSQL and Apache Cassandra are trademarks of their owners; cloudimg is not affiliated with or endorsed by any of them.