Warp 10

In the Azure portal, choose Create a resource. Search for Warp 10 on Ubuntu 24.04 LTS by SecureAnyCloud and select Create. Pick your subscription, resource group and region, the Standard_B2s size and your SSH public key for the administrator account.

Under Networking, allow inbound 22 and 443 (and 80 if you want the redirect). The image brings its own 30 GiB data disk for Warp 10. You can enlarge it on the Disks tab, and first boot grows the file system to the disk.

Or deploy with the Azure CLI, replacing the values in angle brackets:

az group create --name warp10-rg --location <region>
az vm image terms accept --urn sac1647283583153:warp10:default:latest
az vm create --resource-group warp10-rg --name warp10 \
  --image sac1647283583153:warp10:default:latest \
  --size Standard_B2s --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub --public-ip-sku Standard
az vm open-port --resource-group warp10-rg --name warp10 --port 443 --priority 900

ssh azureuser@<vm-public-ip>

First boot generates the certificate, the keys, the empty store, the tokens and the password. Then Warp 10 and nginx start. Allow about a minute after the VM reaches the running state, then check the services:

systemctl is-active warp10 nginx warp10-firstboot
sudo test -f /var/lib/sac/data/warp10-firstboot.done && echo FIRSTBOOT_DONE ls /opt/warp10/bin/warp10-*.jar java -version 2>&1 | head -1

active active active FIRSTBOOT_DONE /opt/warp10/bin/warp10-3.5.0.jar openjdk version "17.0.20.1" 2026-08-18

Only SSH and nginx listen on public addresses. Warp 10 (port 8080) is on loopback:

sudo ss -Hlntp | awk '{print $4, $6}' | grep -vE '127\.0\.0\.5[34]' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g' | sort

0.0.0.0:22 users:(("sshd"),("systemd")) 0.0.0.0:443 users:(("nginx"),("nginx"),("nginx")) 0.0.0.0:80 users:(("nginx"),("nginx"),("nginx")) 127.0.0.1:8080 users:(("java")) [::]:22 users:(("sshd"),("systemd")) [::]:443 users:(("nginx"),("nginx"),("nginx")) [::]:80 users:(("nginx"),("nginx"),("nginx"))

The URLs, the WarpStudio user and your application name are in the root-only credentials file:

sudo grep -E '^WARP10_(URL|API_URL|STUDIO_USER|APPLICATION)=' /root/warp10-credentials.txt

WARP10_URL=https://<vm-public-ip>/ WARP10_API_URL=https://<vm-public-ip>/api/v0 WARP10_STUDIO_USER=admin WARP10_APPLICATION=sac-<uuid>

The same file holds three secrets, unique to this VM: WARP10_STUDIO_PASSWORD (WarpStudio and WarpScript execution), WARP10_WRITE_TOKEN (writes and deletes) and WARP10_READ_TOKEN (reads). To read one, run for example sudo grep '^WARP10_READ_TOKEN=' /root/warp10-credentials.txt. Keep the secrets in your password manager.

Your VM's Warp 10 keys are in /etc/warp10/secrets.conf (root only). Include that file in your backups, because tokens and the store's metadata are useless without it. Never copy it to another server.

The URLs use the VM's public IP address, taken from the Azure Instance Metadata Service at first boot (or its private IP address when it has no public IP). The certificate names that address, the VM's private IP address and loopback:

openssl x509 -in /etc/ssl/warp10/warp10.crt -noout -subject -ext subjectAltName -enddate

subject=CN = <vm-public-ip>, O = sac X509v3 Subject Alternative Name: IP Address:<vm-public-ip>, IP Address:<vm-private-ip>, IP Address:127.0.0.1, DNS:localhost notAfter=<date about 27 months after first boot>

Without the password, WarpStudio and WarpScript execution answer 401, a wrong password is refused and port 80 redirects to HTTPS. The commands below read the password from the credentials file into a shell variable. They pass it to curl through a file descriptor, so it never appears in the process list or your shell history:

H=$(sudo sed -n 's#^WARP10_URL=https://\([^/]*\)/.*#\1#p' /root/warp10-credentials.txt)
PW=$(sudo sed -n 's/^WARP10_STUDIO_PASSWORD=//p' /root/warp10-credentials.txt) R=(--cacert /etc/ssl/warp10/warp10.crt --resolve "$H:443:127.0.0.1") curl -s -o /dev/null -w 'http:// /api/v0/exec -> %{http_code} %{redirect_url}\n' --resolve "$H:80:127.0.0.1" "http://$H/api/v0/exec" curl -s -o /dev/null -w 'WarpStudio, no login -> HTTP %{http_code}\n' "${R[@]}" "https://$H/" curl -s -o /dev/null -w 'WarpStudio, wrong password -> HTTP %{http_code}\n' "${R[@]}" -K <(printf 'user = "admin:admin"\n') "https://$H/" curl -s -o /dev/null -w 'WarpStudio, your password -> HTTP %{http_code}\n' "${R[@]}" -K <(printf 'user = "admin:%s"\n' "$PW") "https://$H/" printf '1 1 +' | curl -s -o /dev/null -w 'exec, no login -> HTTP %{http_code}\n' "${R[@]}" --data-binary @- "https://$H/api/v0/exec" printf '6 7 *' | curl -s -w ' <- exec, your password\n' "${R[@]}" -K <(printf 'user = "admin:%s"\n' "$PW") --data-binary @- "https://$H/api/v0/exec" curl -s -w ' <- /healthz (no login)\n' "${R[@]}" "https://$H/healthz"

http:// /api/v0/exec -> 301 https://<vm-public-ip>/api/v0/exec WarpStudio, no login -> HTTP 401 WarpStudio, wrong password -> HTTP 401 WarpStudio, your password -> HTTP 200 exec, no login -> HTTP 401 [42] <- exec, your password ok <- /healthz (no login)

--resolve sends the request to this VM while keeping the real host name, so the certificate check passes. From another machine, drop --resolve and use the URL directly. Point --cacert at a copy of the certificate, or use -k while you test. WarpScript execution returns the stack as JSON ([42]).

Data goes in through /api/v0/update in Warp 10's text format, one datapoint per line: <timestamp in microseconds>/<lat:lon>/<elevation> <class>{<labels>} <value> (location and elevation may be left empty). Send the WRITE token in the X-Warp10-Token header.

This example writes six temperature readings a minute apart. It shows that a request without a token and a request with the READ token are both refused. It then reads the last three values back through /api/v0/fetch with the READ token. Finally it runs a WarpScript FETCH that returns the number of readings and the highest value. The tokens are handed to curl through a file descriptor too:

H=$(sudo sed -n 's#^WARP10_URL=https://\([^/]*\)/.*#\1#p' /root/warp10-credentials.txt)
WT=$(sudo sed -n 's/^WARP10_WRITE_TOKEN=//p' /root/warp10-credentials.txt)
RT=$(sudo sed -n 's/^WARP10_READ_TOKEN=//p' /root/warp10-credentials.txt)
PW=$(sudo sed -n 's/^WARP10_STUDIO_PASSWORD=//p' /root/warp10-credentials.txt) R=(--cacert /etc/ssl/warp10/warp10.crt --resolve "$H:443:127.0.0.1")
NOW=$(date +%s) for i in 0 1 2 3 4 5; do printf '%s000000// demo.temperature{room=lab} %s\n' "$((NOW - 300 + i * 60))" "$((20 + i))"; done \
  | curl -s -o /dev/null -w 'update, write token -> HTTP %{http_code}\n' "${R[@]}" -H @<(printf 'X-Warp10-Token: %s\n' "$WT") --data-binary @- "https://$H/api/v0/update" printf '%s000000// demo.temperature{room=lab} 99\n' "$NOW" | curl -s -o /dev/null -w 'update, no token -> HTTP %{http_code}\n' "${R[@]}" --data-binary @- "https://$H/api/v0/update" printf '%s000000// demo.temperature{room=lab} 99\n' "$NOW" | curl -s -o /dev/null -w 'update, read token -> HTTP %{http_code}\n' "${R[@]}" -H @<(printf 'X-Warp10-Token: %s\n' "$RT") --data-binary @- "https://$H/api/v0/update" curl -s "${R[@]}" -H @<(printf 'X-Warp10-Token: %s\n' "$RT") "https://$H/api/v0/fetch?selector=demo.temperature%7Broom=lab%7D&now=$(( (NOW + 60) * 1000000 ))&timespan=-3&format=text" | sed -E 's/^[0-9]+/<time>/; s/^=[0-9]+/=<time>/; s/\.app=[^,}]*/.app=sac-<uuid>/' curl -s -o /dev/null -w 'fetch, no token -> HTTP %{http_code}\n' "${R[@]}" "https://$H/api/v0/fetch?selector=demo.temperature%7Broom=lab%7D&now=$(( (NOW + 60) * 1000000 ))&timespan=-3" printf "[ '%s' 'demo.temperature' { 'room' 'lab' } NOW 1 h ] FETCH 0 GET VALUES DUP SIZE SWAP MAX" "$RT" \
  | curl -s -w ' <- WarpScript FETCH: count, max\n' "${R[@]}" -K <(printf 'user = "admin:%s"\n' "$PW") --data-binary @- "https://$H/api/v0/exec"

update, write token -> HTTP 200 update, no token -> HTTP 403 update, read token -> HTTP 403 <time>// demo.temperature{.app=sac-<uuid>,room=lab} 25 =<time>// 24 =<time>// 23 fetch, no token -> HTTP 403 [25,6] <- WarpScript FETCH: count, max

Every series written with your WRITE token carries your application name in the .app label, and your READ token can read only your application's series. The token travels in a header or in the body of a request, never in a URL. Keep it that way: nginx on this image does not log query strings, but other proxies may. Telegraf, Node-RED, the Warp 10 client libraries and any HTTP client can push data the same way.

Open the WARP10_URL from Step 4 (https://<vm-public-ip>/) in a browser. The certificate is self-signed, so the browser warns once. Accept it, or install your own certificate (Step 10). The browser then asks for a user and password. Sign in as admin with WARP10_STUDIO_PASSWORD.

WarpStudio opens on the Code tab. In the backend selector at the top, choose This instance (<your-host>). The image adds it to WarpStudio's list for you. The other backend WarpStudio knows, the SenX public sandbox, is blocked by this image's content security policy, so your scripts and tokens never leave your VM.

Type a script and choose the blue run button. The stack appears under Results. This script builds a one-hour synthetic series with WarpScript alone (no token needed):

NEWGTS 'demo.sine' RENAME { 'source' 'warpstudio' } RELABEL 'g' STORE 0 59 <% 'i' STORE $g NOW $i 60000000 * - NaN NaN NaN $i 10.0 / SIN ADDVALUE DROP %> FOR $g SORT

The Dataviz tab plots the series on the stack:

The Tabular View tab lists the datapoints:

To read stored data in WarpStudio, put your READ token in a FETCH, for example [ '<your-read-token>' 'demo.temperature' {} NOW 1 h ] FETCH. Anything you type in WarpStudio is stored in your browser only.

Give each application its own tokens rather than sharing yours. A root-only helper mints tokens on the VM with your VM's keys, from a WarpScript envelope file that describes them. Write the envelope to a file only root can read, run the helper and keep its output somewhere safe. The helper prints the tokens as JSON:

sudo install -m 0600 /dev/null /root/telegraf-tokens.mc2
sudo nano /root/telegraf-tokens.mc2
sudo warp10-tokengen /root/telegraf-tokens.mc2

A WRITE token for an application called telegraf, valid for a year, looks like this. Owner and producer are UUIDs you choose. Reuse them in matching READ tokens:

{ 'id' 'TelegrafWrite' 'type' 'WRITE' 'application' 'telegraf' 'owner' '<uuid>' 'producer' '<uuid>' 'issuance' NOW MSTU / 'expiry' NOW 365 d + MSTU / 'labels' { } 'attributes' { } } TOKENGEN

See the Warp 10 documentation on tokens and TOKENGEN for READ tokens, label restrictions and capabilities. To withdraw a token before it expires, use Warp 10's token revocation list (warp.trl.dir, described in the Warp 10 documentation). Generating new keys invalidates every token at once.

WarpScript runs inside the Warp 10 service as the unprivileged warp10 user. The functions that reach outside the database are switched off for every script (the sandbox bootstrap /opt/warp10/etc/bootstrap/sac-sandbox.mc2). No extension is loaded, and administrative functions need capabilities your tokens do not carry:

H=$(sudo sed -n 's#^WARP10_URL=https://\([^/]*\)/.*#\1#p' /root/warp10-credentials.txt)
PW=$(sudo sed -n 's/^WARP10_STUDIO_PASSWORD=//p' /root/warp10-credentials.txt) R=(--cacert /etc/ssl/warp10/warp10.crt --resolve "$H:443:127.0.0.1") ws() { printf '%-72s -> ' "$1"; printf '%s' "$1" | curl -s -D - -o /dev/null "${R[@]}" -K <(printf 'user = "admin:%s"\n' "$PW") --data-binary @- "https://$H/api/v0/exec" | sed -n 's/^x-warp10-error-message: .*(\([^()]*\))*\r*$/\1/Ip'; } ws "'file:///etc/shadow' PloadShape" ws "'http://169.254.169.254/metadata/instance?api-version=2021-02-01' PloadShape" ws "'cmd' 'testcall.sh' CALL" ws "'hello' LOGMSG" ws "'https://example.com/' HTTP" ws "'https://example.com/macros/' WF.ADDREPO" ws "'snap1' LEVELDBSNAPSHOT" ls -A /opt/warp10/calls | wc -l
# the CALL directory is empty

'file:///etc/shadow' PloadShape -> PloadShape is undefined. 'http://169.254.169.254/metadata/instance?api-version=2021-02-01' PloadShape -> PloadShape is undefined. 'cmd' 'testcall.sh' CALL -> CALL is undefined. 'hello' LOGMSG -> LOGMSG is undefined. 'https://example.com/' HTTP -> Unknown function 'HTTP' 'https://example.com/macros/' WF.ADDREPO -> WF.ADDREPO expects the capability 'wfset' to be set. 'snap1' LEVELDBSNAPSHOT -> LEVELDBSNAPSHOT missing capability 'leveldb.admin' or 'leveldb.snapshot'. 0

These are the service settings behind it, followed by a probe from inside the Warp 10 service. Neither the Azure Instance Metadata Service, nor the Azure wire server, nor any other host is reachable. Only Warp 10 itself is, on loopback:

systemctl show warp10 -p User -p NoNewPrivileges -p ProtectSystem -p ProtectHome -p PrivateTmp -p ReadWritePaths -p IPAddressDeny -p IPAddressAllow -p LimitCORE
systemctl show nginx -p IPAddressDeny -p LimitCORE
CG=$(systemctl show -p ControlGroup --value warp10)
sudo bash -c "echo \$\$ > /sys/fs/cgroup$CG/cgroup.procs; curl -s -m 5 -o /dev/null -w 'from inside warp10: Azure metadata service -> %{http_code}\n' -H Metadata:true 'http://169.254.169.254/metadata/instance?api-version=2021-02-01'; curl -s -m 5 -o /dev/null -w 'from inside warp10: Azure wire server -> %{http_code}\n' 'http://168.63.129.16/?comp=versions'; curl -s -m 5 -o /dev/null -w 'from inside warp10: https://azure.microsoft.com/ -> %{http_code}\n' https://azure.microsoft.com/; curl -s -m 5 -o /dev/null -w 'from inside warp10: loopback Warp 10 -> %{http_code}\n' http://127.0.0.1:8080/api/v0/check"

IPAddressAllow=127.0.0.0/8 ::1/128 IPAddressDeny=0.0.0.0/0 ::/0 LimitCORE=0 User=warp10 ReadWritePaths=/var/lib/warp10 PrivateTmp=yes ProtectHome=yes ProtectSystem=strict NoNewPrivileges=yes IPAddressDeny=169.254.169.254/32 168.63.129.16/32 LimitCORE=0 from inside warp10: Azure metadata service -> 000 from inside warp10: Azure wire server -> 000 from inside warp10: https://azure.microsoft.com/ -> 000 from inside warp10: loopback Warp 10 -> 200

Warp 10 cannot read /etc/shadow, the TLS key, the credentials file, the key file in /etc/warp10 or the nginx password file. Those paths are root-only or hidden from the service. The service receives its keys through a systemd credential.

If you need a WarpScript extension (for example the HTTP extension for outbound calls), enable it in a file in /opt/warp10/etc/conf.d. Then relax the network settings in /etc/systemd/system/warp10.service.d/ deliberately and restart: sudo systemctl daemon-reload && sudo systemctl restart warp10.

Warp 10 keeps its LevelDB store under /var/lib/warp10/leveldb, its logs under /var/lib/warp10/logs and its temporary files under /var/lib/warp10/tmp, all on the dedicated Azure data disk. The JVM runs with a 1.5 GB heap, sized for Standard_B2s:

df -h /var/lib/warp10 | tail -1 | awk '{print $2" total, "$4" free on "$6}'
sudo ls /var/lib/warp10 /var/lib/warp10/logs grep -oE -- '-Xmx[0-9a-z]+' /usr/local/lib/sac/warp10-run

30G total, 28G free on /var/lib/warp10 /var/lib/warp10: leveldb logs lost+found tmp /var/lib/warp10/logs: warp10-init.log warp10.log warpscript.out -Xmx1536m

• Heap. On a larger VM raise -Xmx1536m in /usr/local/lib/sac/warp10-run (about half of the VM's memory is a good start), then sudo systemctl restart warp10.
• Disk. To grow the data disk, stop (deallocate) the VM. Increase the disk's size in the portal (Disks, then the data disk, Size + performance) or with az disk update --size-gb. Then start the VM and extend the file system: sudo resize2fs "$(findmnt -no SOURCE /var/lib/warp10)".
• Backups. Stop Warp 10 (sudo systemctl stop warp10), take a snapshot of the data disk and back up /etc/warp10/secrets.conf with it. Alternatively, use LEVELDBSNAPSHOT with a token that carries the leveldb.snapshot capability. Restore a snapshot as a whole disk together with its key file. First boot never runs again on a VM that has completed it, and Warp 10 refuses to start without a store.
• Configuration. The upstream configuration templates are in /opt/warp10/etc/conf.d, and SecureAnyCloud's settings are in 99-sac.conf. Add your own settings in a new file that sorts last (for example 99-zz-local.conf), then restart Warp 10.
• Logs. warp10.log is the main Warp 10 log and warpscript.out the WarpScript log; journalctl -u warp10 shows the service output and journalctl -u warp10-firstboot what first boot did.

The served host name is fixed by configuration, never taken from a request. To serve Warp 10 under your own DNS name, point the name at the VM and run the helper. It records the name, regenerates the self-signed certificate for it, updates WarpStudio's backend and the credentials file, and reloads nginx:

sudo warp10-set-hostname <your-dns-name>

Run the same command if the VM's public IP address changes, because a request for a name the VM does not serve is dropped. A static public IP avoids this.

To use a certificate from your own CA or a public CA instead, replace /etc/ssl/warp10/warp10.crt (full chain) and /etc/ssl/warp10/warp10.key (mode 0600, owner root). Then run sudo nginx -t && sudo systemctl reload nginx.

Root logins, empty passwords and X11 forwarding are switched off in /etc/ssh/sshd_config.d/00-sac.conf, which sorts before every other SSH setting. Whether SSH accepts passwords is the choice you made when you deployed the VM (key authentication by default). Check the effective values:

sudo sshd -T | grep -E '^(permitrootlogin|permitemptypasswords|x11forwarding|pubkeyauthentication|passwordauthentication) '

permitrootlogin no pubkeyauthentication yes passwordauthentication no x11forwarding no permitemptypasswords no

Also follow these security practices:

• Change the WarpStudio password with printf '%s\n' '<new-password>' | openssl passwd -6 -stdin, then replace the hash after admin: in /etc/nginx/warp10.htpasswd, run sudo systemctl reload nginx and update /root/warp10-credentials.txt.
• Anyone with the WarpStudio password can run WarpScript with your VM's resources and read any series a token they hold allows. Give applications tokens, not the password.
• nginx logs the real client address of every request without its query string, and ignores X-Forwarded-For headers sent by clients. Restrict port 443 in your network security group to the networks that use Warp 10.
• Bundled libraries. Warp 10 3.5.0 is the newest Warp 10 release. It bundles libraries that a scanner reports with known advisories. None is reachable from the network in this configuration. Jetty 9.4.51 is reached only through nginx, which re-frames every request, and Warp 10 configures no DIGEST authentication, no request inflation and no HTTP/2 connector. The log4j 1.2.17 advisories need socket, JMS or JDBC appenders or the Chainsaw and SocketServer tools, none of which is configured or run. Jackson is used only for WarpScript's own JSON functions, without polymorphic typing. The commons-beanutils library and the Hadoop, Kafka and ZooKeeper libraries are not used by the standalone edition. The Bouncy Castle advisories concern GOST, certificate path validation and malformed ASN.1 or PGP input, which only a user with the WarpStudio password can feed to WarpScript's PGP functions. WarpStudio's own embedded web server is not installed: nginx serves its files. SecureAnyCloud updates the image when SenX ships a Warp 10 release with newer libraries.

When you have finished with the example data from Step 5, delete it with the WRITE token:

H=$(sudo sed -n 's#^WARP10_URL=https://\([^/]*\)/.*#\1#p' /root/warp10-credentials.txt)
WT=$(sudo sed -n 's/^WARP10_WRITE_TOKEN=//p' /root/warp10-credentials.txt)
curl -s -w 'delete, write token -> HTTP %{http_code}\n' --cacert /etc/ssl/warp10/warp10.crt --resolve "$H:443:127.0.0.1" -H @<(printf 'X-Warp10-Token: %s\n' "$WT") "https://$H/api/v0/delete?deleteall=true&selector=demo.temperature%7Broom=lab%7D" | sed -E 's/\.app=[^,}]*/.app=sac-<uuid>/'

The response lists the series that were deleted:

demo.temperature{.app=sac-<uuid>,room=lab}{} delete, write token -> HTTP 200