Liftbridge

• Open the Liftbridge offer on the Azure Marketplace and choose Get It Now, then Create.
• Select your subscription, resource group and region, and choose the Standard_B2s size.
• Provide your SSH public key for the azureuser account.
• Allow inbound TCP 22 and TCP 9292 in the Network Security Group, then create the VM.

Accept the Marketplace terms once per subscription, then create the VM:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:liftbridge:default:latest
az vm create \
  --resource-group my-rg \
  --name liftbridge-01 \
  --image sac1647283583153:liftbridge:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

On the first boot of every VM, liftbridge-firstboot.service generates a unique certificate authority, a server certificate (covering this VM's public IP, its private IP, and localhost) and a client certificate. It renders the Liftbridge config with them and starts liftbridge.service.

It then runs a real create-stream, publish and subscribe round trip over the freshly minted mutual TLS connection. This proves the node works before first boot finishes. A broken certificate or a broken server makes first boot fail loudly instead of silently reporting done.

First boot completes in well under a minute. Give it a moment before you connect.

SSH in as azureuser. Confirm that the service is active, then check the version and the listening surface:

systemctl is-active liftbridge liftbridge-firstboot liftbridge --version ss -tln sudo stat -c '%a %U:%G %n' /root/liftbridge-credentials.txt

The output shows:

• active for both services
• Version 26.01.1
• A listener on :9292 (Liftbridge's mutual-TLS API, reachable from anywhere) and on 127.0.0.1:4222 (the embedded NATS server, loopback-only)
• The credentials file at 0600 root:root

Liftbridge ships no CLI of its own, so this image includes lift-cli at /usr/local/bin/lift-cli. It is a small wrapper that SecureAnyCloud built on the official go-liftbridge client library. Every command needs the three files that first boot generated:

sudo lift-cli create \
  -addr 127.0.0.1:9292 \
  -ca /etc/liftbridge/tls/ca-cert.pem \
  -cert /etc/liftbridge/tls/client-cert.pem \
  -key /etc/liftbridge/tls/client-key.pem \
  -stream demo-orders -subject demo.orders
sudo lift-cli publish \
  -addr 127.0.0.1:9292 \
  -ca /etc/liftbridge/tls/ca-cert.pem \
  -cert /etc/liftbridge/tls/client-cert.pem \
  -key /etc/liftbridge/tls/client-key.pem \
  -stream demo-orders -message 'order-42 placed at 2026-08-09T01:00:00Z'

The create command attaches a new durable stream to the NATS subject demo.orders. The publish command writes one message to the stream and reports the offset it landed at.

Read the stream from the beginning. This is the consume half of the round trip. Liftbridge is a durable log, not a queue, so reading it again returns the same message instead of draining it:

sudo lift-cli subscribe \
  -addr 127.0.0.1:9292 \
  -ca /etc/liftbridge/tls/ca-cert.pem \
  -cert /etc/liftbridge/tls/client-cert.pem \
  -key /etc/liftbridge/tls/client-key.pem \
  -stream demo-orders -start earliest -count 1

The -start earliest option reads from the beginning of the log. Use -start latest to pick up only new messages, or -count 0 to stream continuously.

Two checks prove that the streaming API is not reachable without a valid per-VM client certificate. A plaintext connection gets no data back, because the server only ever speaks TLS. A client that presents no certificate at all is rejected outright by the TLS handshake itself.

timeout 5 bash -c 'exec 3<>/dev/tcp/127.0.0.1/9292 && printf "" >&3 && head -c1 <&3' || true
sudo lift-cli metadata -addr 127.0.0.1:9292 -insecure || true

Both commands are expected to fail, and that failure is the proof. The || true only keeps your shell's exit status clean. The rejection message printed above is the evidence.

The certificate authority, server certificate and client certificate all live under /etc/liftbridge/tls/ on the VM, owned by root. Copy the CA certificate and the client certificate and key to wherever you will run lift-cli or your own go-liftbridge client. Use sudo cat over SSH, because scp alone cannot read a root-only file as azureuser:

ssh azureuser@<vm-ip> "sudo cat /etc/liftbridge/tls/ca-cert.pem" > ca-cert.pem
ssh azureuser@<vm-ip> "sudo cat /etc/liftbridge/tls/client-cert.pem" > client-cert.pem
ssh azureuser@<vm-ip> "sudo cat /etc/liftbridge/tls/client-key.pem" > client-key.pem

Then connect to the VM's public IP on port 9292 from your own machine:

lift-cli metadata -addr <vm-ip>:9292 -ca ca-cert.pem -cert client-cert.pem -key client-key.pem

Every consumer or producer of this stream needs its own client certificate signed by the same per-VM CA. The CA's private key stays on the VM so that you can issue more certificates without redeploying:

sudo openssl genrsa -out /etc/liftbridge/tls/app2-key.pem 2048
sudo openssl req -new -key /etc/liftbridge/tls/app2-key.pem -out /tmp/app2.csr -subj "/CN=app2"
sudo openssl x509 -req -in /tmp/app2.csr \
  -CA /etc/liftbridge/tls/ca-cert.pem -CAkey /etc/liftbridge/tls/ca-key.pem -CAcreateserial \
  -out /etc/liftbridge/tls/app2-cert.pem -days 3650 -sha256 sudo rm -f /tmp/app2.csr

Print the credentials file:

sudo cat /root/liftbridge-credentials.txt

This file records the resolved host and port and the paths to the CA, client certificate and client key generated for this VM. It holds everything lift-cli (or your own client) needs to connect.

• Restrict TCP 9292 in the Network Security Group to the networks that need to publish or consume, unless you intend to expose it broadly.
• Treat /etc/liftbridge/tls/ca-key.pem as sensitive, because anyone who can read it can mint a trusted client certificate. It is root-only (0600) by default.
• Keep the OS patched. The image ships fully updated and with unattended security upgrades enabled.
• Leave the embedded NATS server (127.0.0.1:4222) as it is. It is intentionally loopback-only and has nothing to configure. It is Liftbridge's own internal transport, never a customer-facing endpoint.

Liftbridge is free and open source software distributed under the Apache License 2.0. This image bundles the official upstream release binary unmodified. lift-cli is SecureAnyCloud's own small addition, built on the official go-liftbridge client library (also Apache-2.0). Your use of Liftbridge is governed by its license.

SecureAnyCloud is not affiliated with, endorsed by, or sponsored by the Liftbridge project, its maintainers, or Basekick Labs.

SecureAnyCloud images come with 24/7 support. If you need help deploying or configuring Liftbridge on Azure, contact us.

Deploy on Azure

Find this image on the Azure Marketplace and deploy in minutes.

Need Help?

Email sales@secureanycloud.com and our team will help you get up and running.

Deploy on Azure

Launch Liftbridge 26.01.1 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