Deployment guide

wasmCloud

Overview

wasmCloud is a Cloud Native Computing Foundation (CNCF) platform for running WebAssembly components in a distributed application mesh called a lattice. A wasmCloud host runs your components and connects them to capability providers, such as HTTP servers, key-value stores and message brokers, over a NATS message bus. The wasmCloud Application Deployment Manager (wadm) reconciles the applications you declare against the running hosts, so you describe the desired state and the platform keeps it running. Components are portable, sandboxed WebAssembly, so the same artifact runs anywhere a host runs.

This SecureAnyCloud image installs a complete single-node wasmCloud environment on one machine, from pinned upstream releases that are each verified by SHA-256. A sample hello-world HTTP component and the httpserver capability provider are deployed by wadm on boot, so the platform is serving HTTP the moment the VM is up.

NATS ships no authentication of its own, so it is bound to the loopback interface only and is never reachable off the VM. The host, wadm and wash all reach it over 127.0.0.1. nginx terminates TLS on port 443 and fronts the washboard web UI, the demo endpoint and the NATS websocket that the browser washboard connects over. HTTP Basic Auth guards the whole surface.

At first boot, wasmcloud-firstboot.service generates the Basic Auth password and TLS certificate of this VM and writes them to /root/wasmcloud-credentials.txt (mode 0600, root-only). There is no shared or default login in the image.

What you get:

  • wasmCloud host 1.9.2 (/opt/wasmcloud/bin/wasmcloud, Apache-2.0), run by wasmcloud.service
  • NATS 2.14.5 with JetStream (nats.service), the lattice bus, bound to 127.0.0.1 only
  • wadm 0.21.1 (wadm.service), which reconciles declared applications
  • wash 0.43.0 (/opt/wasmcloud/bin/wash), the wasmCloud Shell CLI, and the washboard web UI (wash-ui.service)
  • All four components run as hardened systemd services under a dedicated wasmcloud user
  • A sample hello-world HTTP component and httpserver provider, deployed on boot by wasmcloud-app-deploy.service
  • The washboard web UI and demo endpoint fronted by nginx TLS on 443 with per-VM HTTP Basic Auth
  • wasmcloud-firstboot.service, which creates the per-VM Basic Auth password and TLS certificate
  • An Ubuntu 24.04 LTS base with the latest security patches applied at build time
  • 24/7 SecureAnyCloud support, 24h response SLA

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet. Standard_B2s is the recommended VM size for evaluation and demonstration. Scale up for heavier workloads.

You reach the washboard over HTTPS (port 443). NATS needs no inbound port, and none is opened, because the lattice bus is private to the VM.

Deploy the image

Create a VM from the offer with a network security group (NSG) that allows inbound 22 (SSH) and 443 (HTTPS). Port 80 redirects to 443.

Everything else binds 127.0.0.1 and is never exposed off the VM: the NATS client bus (4222), the NATS websocket (4223), the washboard (3030) and the demo httpserver (8080).

When the VM is running, connect over SSH as azureuser:

ssh azureuser@<public-ip>

First-boot posture

Every service is enabled and starts on boot. The wasmCloud and NATS surfaces bind loopback only, and nginx is the single public front door. Confirm the posture:

systemctl is-active nats wasmcloud wadm wash-ui nginx /opt/wasmcloud/bin/wasmcloud --version ss -tlnH | awk '{print $4}' | grep -E ':(443|4222|4223|3030|8080)$' | sort swapon --show | wc -l

In the expected output, the four platform services and nginx are active, NATS and the washboard bind loopback only, and no swap ships on the OS disk:

active active active active active wasmcloud 1.9.2 0.0.0.0:443 127.0.0.1:3030 127.0.0.1:4222 127.0.0.1:4223 127.0.0.1:8080 0

Retrieve your per-VM credentials

The washboard and the demo endpoint are served over TLS behind HTTP Basic Auth. The password is generated uniquely on each VM at first boot and written to a root-only file. Read it with:

sudo cat /root/wasmcloud-credentials.txt

Expected output (the password is unique to your VM):

# wasmCloud on Ubuntu 24.04 — Per-VM Credentials
# Washboard web UI (HTTPS via nginx): https://<public-ip>/
# Demo hello-world HTTP component: https://<public-ip>/demo/?name=sac
# Sign in (HTTP Basic Auth): sac / <password below>
#
# NATS lattice bus is bound to 127.0.0.1 only and is NOT reachable off-host.
# WASMCLOUD_USER=sac WASMCLOUD_PASSWORD=<set-at-first-boot> WASMCLOUD_URL=https://<public-ip>/ WASMCLOUD_DEMO_URL=https://<public-ip>/demo/?name=sac

The nginx front door enforces this credential. It rejects a request with no credentials or with a guessed one, and it accepts the per-VM credential:

PASS=$(sudo grep '^WASMCLOUD_PASSWORD=' /root/wasmcloud-credentials.txt | cut -d= -f2-)
curl -sk -o /dev/null -w 'healthz %{http_code}\n' https://127.0.0.1/healthz
curl -sk -o /dev/null -w 'no auth %{http_code}\n' https://127.0.0.1/
curl -sk -o /dev/null -w 'guess %{http_code}\n' -u admin:admin https://127.0.0.1/
curl -sk -o /dev/null -w 'per-VM cred %{http_code}\n' -u "sac:$PASS" https://127.0.0.1/

In the expected output, the static health probe answers, unauthenticated and guessed requests are challenged (401), and the per-VM credential is accepted (200):

healthz 200 no auth 401 guess 401 per-VM cred 200

The sample application is already running

wadm deployed the bundled hello-world application on boot. The HTTP component answers immediately, both locally and through the TLS front door. Request it both ways:

PASS=$(sudo grep '^WASMCLOUD_PASSWORD=' /root/wasmcloud-credentials.txt | cut -d= -f2-)
curl -s http://127.0.0.1:8080/
curl -sk -u "sac:$PASS" https://127.0.0.1/demo/

Expected output:

Hello from Rust! Hello from Rust!

Inspect the lattice from the command line

wash talks to the local lattice with no configuration, because it uses the default loopback NATS and the default lattice. List the running host, the deployed components and providers, and the applications that wadm manages:

wash get hosts wash get inventory wash app list

In the expected output, one host runs the hello-world component and the httpserver provider, and wadm reports the application as Deployed:

Host ID Friendly name Uptime (seconds) NAVVAEXCCUF4UBWHKY3DLMXWWKPIVCRGSUJUO6W2W55G6AOZKF2R74HA cold-dream-6979 147 Component ID Name Max count hello_world-http_component http-hello-world 1 Provider ID Name hello_world-httpserver http-server-provider Name Deployed Version Status hello-world v0.0.1 Deployed

The washboard web UI

Browse to https://<public-ip>/ and sign in with the Basic Auth user SecureAnyCloud and the per-VM password from /root/wasmcloud-credentials.txt. The certificate is self-signed and generated per VM, so your browser warns on the first visit. Accept the warning, or install a CA-signed certificate as described below.

The washboard connects to the lattice through the nginx TLS proxy and shows the live state: the connected host, the deployed component and provider, and the link that wires them together. Expand the host to see its labels and the components and providers it is running.

The Components and Providers tables list the deployed hello-world component and the httpserver provider, with its health showing Running.

The Links table shows the wasi:http/incoming-handler link that connects the httpserver provider to the hello-world component. This link turns an inbound HTTP request into a component invocation.

Deploy your own components

The bundled application manifest lives at /opt/wasmcloud/apps/hello-world.wadm.yaml. wadm applications are declared as OAM manifests. You list the components and capability providers you want and the links between them, and wadm keeps the lattice reconciled to that declaration. Inspect and manage the running application with wash:

wash app get hello-world cat /opt/wasmcloud/apps/hello-world.wadm.yaml

To deploy your own WebAssembly component, publish it to an OCI registry or reference a local .wasm file. Write a manifest that references it, then run wash app deploy <your-manifest>.yaml.

The wasmCloud documentation covers building components in Rust, Go, TypeScript and other languages, and lists the full catalogue of capability providers. It also explains how to scale a component across multiple hosts by raising its spreadscaler instance count.

Add a custom domain and a CA-signed certificate

The image ships a per-VM self-signed certificate, so HTTPS works out of the box. For production, point a DNS name at the VM and install a CA-signed certificate. Replace the certificate and key that nginx serves:

sudo cp <your-domain>.crt /etc/nginx/ssl/wasmcloud.crt
sudo cp <your-domain>.key /etc/nginx/ssl/wasmcloud.key
sudo systemctl reload nginx

To change the washboard Basic Auth password at any time, run:

sudo htpasswd -bB /etc/nginx/.wasmcloud.htpasswd sac '<new-password>'
sudo systemctl reload nginx

Security model

  • NATS is private to the VM. The lattice bus binds 127.0.0.1 only (client 4222 and websocket 4223) and is never reachable off the machine. The host, wadm and wash reach it over loopback. The browser washboard reaches it through the authenticated nginx TLS proxy.
  • No default credential ships. No NATS auth account exists and no nginx password file is baked into the image. nginx refuses to start until first boot has created the Basic Auth password and TLS certificate of this VM, so no shared or guessable login is ever present.
  • Single public surface. Only SSH (22), the HTTP-to-HTTPS redirect (80) and the TLS front door (443) are exposed. The washboard (3030), the demo httpserver (8080) and the NATS ports all bind loopback and sit behind nginx.
  • Fully patched base. Ubuntu 24.04 LTS is patched at build time with unattended security updates enabled on your running VM.

Support

SecureAnyCloud provides 24/7 technical support for this wasmCloud image by email (sales@secureanycloud.com) and live chat. Support covers deployment, retrieving and rotating the first-boot password, adding a custom domain and CA-signed certificate, and deploying your own WebAssembly components and capability providers. It also covers scaling the lattice, upgrades and patch management, and troubleshooting.

Critical issues receive a one-hour average response time.

wasmCloud is a trademark of its respective holder. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

Deploy on Azure

Launch wasmCloud 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