Deployment guide

RisingWave

Overview

RisingWave is a Postgres-compatible streaming database. It speaks the PostgreSQL wire protocol on port 4566, so any psql client or PostgreSQL driver can run streaming SQL against it. That includes sources, materialized views over streams, and continuous queries whose results are kept incrementally up to date.

This SecureAnyCloud image installs RisingWave 3.0.0, the official self-contained risingwave binary from RisingWave Labs, and runs it in standalone single-node mode, where one process hosts the meta, compute, frontend and compactor components. State and metadata are stored on a dedicated Azure data disk, and a unique password is rotated into the image on first boot.

What you get:

RisingWave 3.0.0 (the single all-in-one risingwave binary) from the official GitHub release
Standalone single-node mode (risingwave single-node): meta, compute, frontend and compactor in one process
A unique per-VM password generated on first boot, with no shared default credential
Standalone state and metadata on a dedicated 40 GiB Azure data disk at /var/lib/risingwave
The PostgreSQL wire protocol bound to loopback (127.0.0.1:4566) with password authentication
24/7 SecureAnyCloud support

The PostgreSQL wire protocol listens on 127.0.0.1:4566 only. The port is not opened to the internet, so connect locally on the VM or over an SSH tunnel.

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B4ms (4 vCPU / 16 GiB RAM) is a good starting size.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network. No inbound application ports are needed, because you reach RisingWave over an SSH tunnel.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for RisingWave 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) only.

Then select Review + create, and select Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:risingwave-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name risingwave \
  --image sac1647283583153:risingwave-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

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm RisingWave is installed and running

Check the installed version, the service state and the listening ports:

risingwave --version systemctl is-active risingwave.service risingwave-firstboot.service ss -tln | grep -E ":4566|:5691"

The output shows RisingWave 3.0.0, both services active, and the Postgres wire protocol bound to loopback on 4566:

risingwave 3.0.0 (ef12f3adbc) active active LISTEN 0 1024 0.0.0.0:5691 0.0.0.0:* LISTEN 0 1024 127.0.0.1:4566 0.0.0.0:*

127.0.0.1:4566 is the PostgreSQL wire protocol, which handles the data plane and authentication, and it is bound to loopback only. 5691 is the read-only meta dashboard. It carries no data and is not opened on the Azure NSG by default.

Step 5 - Retrieve your per-VM password

Each VM generates its own unique RisingWave password on first boot and writes it to a credentials file that only root can read:

sudo cat /root/risingwave-credentials.txt

The file contains RISINGWAVE_PASSWORD, the connection details and the SSH tunnel instructions. Store the password in your secrets manager. In the commands that follow, <RISINGWAVE_PASSWORD> stands for the value of RISINGWAVE_PASSWORD.

Step 6 - Run streaming SQL with psql

RisingWave is Postgres-compatible, so you connect with the standard psql client. The default database is dev and the default user is root. The example creates a table, defines a materialized view that aggregates over it, inserts rows, and reads the incrementally maintained result.

PGPASSWORD=<RISINGWAVE_PASSWORD> psql -h 127.0.0.1 -p 4566 -U root -d dev <<'SQL' CREATE TABLE sales (region varchar, amount int); CREATE MATERIALIZED VIEW sales_by_region AS SELECT region, sum(amount) AS total FROM sales GROUP BY region; INSERT INTO sales VALUES ('emea', 100), ('emea', 250), ('amer', 400); FLUSH; SELECT * FROM sales_by_region ORDER BY region; SQL

CREATE_TABLE CREATE_MATERIALIZED_VIEW INSERT 0 3 FLUSH region | total --------+------- amer | 400 emea | 350 (2 rows)

RisingWave keeps the sales_by_region materialized view up to date automatically as new rows arrive in sales. This is the core of streaming SQL.

Step 7 - Confirm persistence on the dedicated data disk

RisingWave's standalone state and metadata live on the dedicated Azure data disk at /var/lib/risingwave. Streams, tables and materialized views therefore survive restarts, and you can resize the volume independently. Confirm the materialized view, the mount and the meta dashboard health:

PGPASSWORD=<RISINGWAVE_PASSWORD> psql -h 127.0.0.1 -p 4566 -U root -d dev \
  -c "SELECT name FROM rw_catalog.rw_materialized_views;" findmnt /var/lib/risingwave du -sh /var/lib/risingwave/state curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:5691/

name ----------------- sales_by_region (1 row) TARGET SOURCE FSTYPE OPTIONS /var/lib/risingwave /dev/sdc ext4 rw,relatime 672K /var/lib/risingwave/state 200

The mount on /dev/sdc confirms that state is on the dedicated data disk, and the 200 confirms that the meta dashboard is serving locally.

Step 8 - Verify the authentication wall

RisingWave enforces the per-VM password on the root user. It accepts the correct password and rejects a wrong one. First, confirm that the correct password authenticates:

PGPASSWORD=<RISINGWAVE_PASSWORD> psql -h 127.0.0.1 -p 4566 -U root -d dev \
  -c "SELECT current_user, version();"

current_user | version --------------+---------------------------------------------------------- root | PostgreSQL 13.14.0-RisingWave-3.0.0 (ef12f3adbcb6...) (1 row)

To see the rejection for yourself, connect with a wrong password, for example PGPASSWORD=<set-at-first-boot> psql -h 127.0.0.1 -p 4566 -U root -d dev -c 'SELECT 1'. RisingWave responds with FATAL: Invalid password, which shows that the datastore is never open without the credential.

Step 9 - Connect remotely over an SSH tunnel

RisingWave's PostgreSQL wire protocol listens on 127.0.0.1:4566 only and is not exposed publicly, which is the secure default. To reach it from your workstation, open an SSH tunnel and point a local psql client at localhost:4566:

# On your workstation:
ssh -L 4566:127.0.0.1:4566 azureuser@<vm-public-ip>
# In another terminal, with a local psql: PGPASSWORD=<RISINGWAVE_PASSWORD> psql -h 127.0.0.1 -p 4566 -U root -d dev -c "SELECT 1;"

For production remote access without a tunnel, bind RisingWave to a private NIC and front it with TLS. Alternatively, open 4566 in your own NSG, restricted to known source ranges. Never expose 4566 to the internet without transport encryption and source restrictions.

Maintenance

Persistence. Standalone state and metadata live on the dedicated data disk at /var/lib/risingwave, so your streams and materialized views survive reboots, and you can resize the volume independently.
Password. The per-VM password is rotated into the root user on first boot. To change it, run ALTER USER root WITH PASSWORD '<new>'; over psql and update your secrets manager.
Service. RisingWave runs as risingwave.service under a dedicated risingwave system user. Restart it with sudo systemctl restart risingwave.service.
Security patches. unattended-upgrades remains enabled, so the OS continues to receive security updates automatically.
Compatibility. RisingWave speaks the PostgreSQL wire protocol, so existing Postgres clients, drivers and tooling connect to 4566 unchanged.

Support

SecureAnyCloud provides 24/7 expert support for this image. To reach the support team, contact sales@secureanycloud.com.

RisingWave is licensed under the Apache License 2.0 and is a trademark of RisingWave Labs. SecureAnyCloud provides this image, which is not affiliated with or endorsed by RisingWave Labs.

Deploy on Azure

Launch RisingWave on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Overview

This SecureAnyCloud image installs RisingWave 3.0.0, the official self-contained risingwave binary from RisingWave Labs, and runs it in standalone single-node mode, where one process hosts the meta, compute, frontend and compactor components. State and metadata are stored on a dedicated EBS data volume, and a unique password is generated on the instance's first boot.

What you get:

RisingWave 3.0.0 (the single all-in-one risingwave binary) from the official GitHub release
Standalone single-node mode (risingwave single-node): meta, compute, frontend and compactor in one process
A unique per-instance password generated on first boot, with no shared default credential
Standalone state and metadata on a dedicated 40 GiB EBS data volume at /var/lib/risingwave
The PostgreSQL wire protocol bound to loopback (127.0.0.1:4566) with password authentication
24/7 SecureAnyCloud support

The PostgreSQL wire protocol listens on 127.0.0.1:4566 only. The port is not opened to the internet, so connect locally on the instance or over an SSH tunnel.

Connecting to your instance

Connect over SSH on port 22 with the key pair that you selected at launch. The default login user for the Ubuntu 24.04 variant is ubuntu:

ssh -i <your-key.pem> ubuntu@<instance-public-ip>

Prerequisites

You need an AWS account, an EC2 key pair in the target region, and a VPC with a subnet. You also need a security group that allows inbound 22/tcp from your management network.

m5.large (2 vCPU / 8 GiB RAM) is a good starting size.

No inbound application ports are needed, because you reach RisingWave over an SSH tunnel.

Step 1 - Launch from the AWS Marketplace

In the AWS Marketplace, search for RisingWave by SecureAnyCloud. Choose Continue to Subscribe, then Continue to Configuration, and then Continue to Launch.

Pick your region, the m5.large instance type, your VPC and subnet, and a security group that allows SSH (22) from your management network. Select your key pair and launch the instance.

Step 2 - Launch from the AWS CLI

aws ec2 run-instances \
  --image-id <risingwave-ami-id> \
  --instance-type m5.large \
  --key-name <your-key> \
  --security-group-ids <sg-allowing-22> \
  --subnet-id <your-subnet> \
  --metadata-options "HttpTokens=required" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=risingwave}]'

The Launch page of the Marketplace listing shows the AMI ID for your region.

Step 3 - Confirm RisingWave is installed and running

Check the installed version, the service state, the listening ports and the meta dashboard health:

risingwave --version systemctl is-active risingwave.service risingwave-firstboot.service ss -tln | grep -E ":4566|:5691" curl -s -o /dev/null -w "HTTP %{http_code}\n" http://127.0.0.1:5691/

The output shows RisingWave 3.0.0, both services active, the Postgres wire protocol bound to loopback on 4566, and the meta dashboard health returning HTTP 200.

Step 4 - Retrieve your per-instance password

Each instance generates its own unique RisingWave password on first boot and writes it to a credentials file that only root can read:

sudo cat /root/risingwave-credentials.txt

The file contains RISINGWAVE_PASSWORD, the connection details and the SSH tunnel instructions. Store the password in your secrets manager.

When you work on the instance itself, load the password into a shell variable so that it never appears on your command line. The examples that follow use the variable PW:

PW=$(sudo grep '^RISINGWAVE_PASSWORD=' /root/risingwave-credentials.txt | cut -d= -f2-)

Step 5 - Run streaming SQL with psql

PW=$(sudo grep '^RISINGWAVE_PASSWORD=' /root/risingwave-credentials.txt | cut -d= -f2-) PGPASSWORD="$PW" psql -h 127.0.0.1 -p 4566 -U root -d dev <<'SQL' CREATE TABLE sales (region varchar, amount int); CREATE MATERIALIZED VIEW sales_by_region AS SELECT region, sum(amount) AS total FROM sales GROUP BY region; INSERT INTO sales VALUES ('emea', 100), ('emea', 250), ('amer', 400); FLUSH; SELECT * FROM sales_by_region ORDER BY region; SQL

RisingWave keeps the sales_by_region materialized view up to date automatically as new rows arrive in sales. This is the core of streaming SQL.

Step 6 - Verify the authentication wall

RisingWave enforces the per-instance password on the root user. It accepts the correct password and rejects a wrong one with FATAL: Invalid password, which shows that the datastore is never open without the credential.

PW=$(sudo grep '^RISINGWAVE_PASSWORD=' /root/risingwave-credentials.txt | cut -d= -f2-)
# Wrong password is rejected (RisingWave answers FATAL: Invalid password): if PGPASSWORD=<set-at-first-boot> psql -h 127.0.0.1 -p 4566 -U root -d dev -c 'SELECT 1' >/dev/null 2>&1; then echo "UNEXPECTED: wrong password was accepted" else echo "wrong password correctly rejected" fi
# Correct password authenticates: PGPASSWORD="$PW" psql -h 127.0.0.1 -p 4566 -U root -d dev \
  -c 'SELECT current_user, version();'

Step 7 - Confirm persistence on the dedicated data volume

RisingWave's standalone state and metadata live on the dedicated EBS data volume at /var/lib/risingwave. Streams, tables and materialized views therefore survive restarts, and you can resize the volume independently:

PW=$(sudo grep '^RISINGWAVE_PASSWORD=' /root/risingwave-credentials.txt | cut -d= -f2-)
findmnt /var/lib/risingwave PGPASSWORD="$PW" psql -h 127.0.0.1 -p 4566 -U root -d dev \
  -c "SELECT name FROM rw_catalog.rw_materialized_views;"

The mount confirms that state is on the dedicated data volume rather than on the OS root disk.

Step 8 - Connect remotely over an SSH tunnel

# On your workstation:
ssh -i <your-key.pem> -L 4566:127.0.0.1:4566 ubuntu@<instance-public-ip>
# In another terminal, with a local psql: PGPASSWORD=<RISINGWAVE_PASSWORD> psql -h 127.0.0.1 -p 4566 -U root -d dev -c "SELECT 1;"

For production remote access without a tunnel, front RisingWave with TLS. Alternatively, open 4566 in your own security group, restricted to known source ranges. Never expose 4566 to the internet without transport encryption and source restrictions.