Sozu
Overview
Sozu (pronounced sou-zou) is an HTTP reverse proxy and load balancer written in Rust. It is fast and memory-safe, and its defining feature is runtime reconfiguration with no downtime. You add or remove clusters, frontends, backends and TLS certificates on a live proxy without dropping a single connection.
This SecureAnyCloud image installs Sozu 2.2.0 from the pinned upstream crate, so the exact version is reproducible. Sozu runs under systemd as the unprivileged sozu user on Ubuntu 24.04 on Azure, and unattended security upgrades keep the base OS patched.
What you get:
- Sozu 2.2.0 installed from the pinned upstream crate, run under systemd as the unprivileged
sozuuser (sozu.service) - A real response out of the box. The appliance ships a tiny, self-contained local backend, a static server bound to
127.0.0.1:8000, and a default cluster that proxies to it. An on-boxcurl http://localhost/returns a real HTTP body through Sozu the moment the VM boots. You then point Sozu at your own backends with one config edit or a runtime CLI command - A built-in local backend (
sozu-backend.serviceon127.0.0.1:8000) so that the appliance answers a real request out of the box - An HTTP listener on :80 and an HTTPS listener on :443 (per-VM TLS), both proxying to a default cluster
- Sozu runs as the unprivileged
sozuuser and binds the privileged ports :80 and :443 using only theCAP_NET_BIND_SERVICELinux capability, never as root - A command and control channel that is a local Unix socket only (
/run/sozu/sozu.sock, mode0750). It is never exposed on a TCP port, so the proxy cannot be reconfigured from the network. ThesozuCLI over SSH is the sole admin path - A per-VM self-signed TLS certificate generated on first boot into
/etc/sozu/tls/and documented in/root/sozu-info.txt(0600). It is never baked into the image, so every VM has unique TLS material
Prerequisites
- An active Azure subscription, an SSH public key, and a VNet plus subnet in the target region
- A subscription to the Sozu listing on Azure Marketplace
- Network Security Group rules allowing TCP 22 (admin) and, for the traffic you want to proxy, TCP 80 and/or TCP 443
Recommended virtual machine size: Standard_B2s (2 vCPU, 4 GB RAM) for a light edge proxy. For higher throughput, use Standard_D2s_v5 or larger.
Deploy from the Azure Portal
Search for Sozu in Marketplace, select the SecureAnyCloud publisher, and click Create.
Configure the Network Security Group to allow TCP 80 and/or TCP 443 from the clients that will reach the proxy, and TCP 22 for administration.
Deploy from the Azure CLI
RG="sozu-prod"; LOCATION="eastus"; VM_NAME="sozu1" IMAGE_URN="sac1647283583153:sozu-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:sozu-ubuntu-24-04:default:latest
az vm create \
--resource-group "$RG" --name "$VM_NAME" \
--image "$IMAGE_URN" \
--size Standard_B2s \
--admin-username azureuser \
--ssh-key-values "$SSH_KEY" \
--public-ip-sku Standard
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 80 --priority 1001
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 443 --priority 1002
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1003First boot
On first boot, the image generates a per-VM self-signed TLS certificate into /etc/sozu/tls/ and writes /root/sozu-info.txt. Then systemd starts the local backend and Sozu. This completes within a few seconds.
SSH in as azureuser and read the appliance info:
sudo cat /root/sozu-info.txtConfirm the services are running
sozu.service runs under systemd as the unprivileged sozu user. Use ss to confirm that Sozu is listening on :80 and :443, and that the local backend is on loopback 127.0.0.1:8000.
systemctl is-active sozu.service sozu-backend.service ps -o user= -C sozu | head -1 ss -tlnp | grep -E ':80 |:443 |127.0.0.1:8000 'A real request flows through Sozu out of the box
The appliance proxies to its built-in local backend, so a request to http://localhost/ returns a real HTML body through Sozu. The default demo vhost sozu.appliance.local and the HTTPS listener, which uses the per-VM certificate, serve the same backend.
# Plain HTTP through Sozu on :80 curl -s http://localhost/ | head -3
# The documented demo vhost on :80 curl -s -H 'Host: sozu.appliance.local' http://localhost/ | grep -o 'sac sozu appliance backend'
# HTTPS on :443 using the per-VM self-signed certificate curl -sk --resolve sozu.appliance.local:443:127.0.0.1 https://sozu.appliance.local/ | grep -o 'sac sozu appliance backend'The control channel is a local Unix socket only
Sozu is administered with the sozu CLI over its command socket, which is a local Unix socket (/run/sozu/sozu.sock). It is never exposed on a TCP port, so the proxy cannot be reconfigured from the network.
sozu status queries the live proxy over that socket. ss confirms that the only network listeners are the proxy's own :80 and :443, and SSH.
ls -l /run/sozu/sozu.sock
sudo sozu --config /etc/sozu/config.toml status
# No control port on the network — only :80, :443 (proxy) and :22 (ssh) listen off-loopback ss -tlnp | awk 'NR>1 {print $4}' | grep -vE '^(127\.|\[::1\])'Review the per-VM TLS material and the secure-by-default config
A unique self-signed TLS certificate is generated on this VM at first boot. Nothing is baked into the image. The config shows the Unix-socket command channel and the default cluster wired to the local backend. Inspect both:
sudo openssl x509 -in /etc/sozu/tls/cert.pem -noout -subject -fingerprint -sha256 grep -E '^command_socket|^\[\[listeners\]\]|^protocol|^address' /etc/sozu/config.toml
sudo stat -c '%n %a %U:%G' /etc/sozu/tls/key.pem /root/sozu-info.txtPoint Sozu at your own backend
Replace the built-in demo backend with your own. Edit /etc/sozu/config.toml to add a frontend for your hostname and a backend pointing at your application. Then reload Sozu with no downtime.
This example routes the hostname app.example.com to a backend on 10.0.0.10:8080:
sudo tee -a /etc/sozu/config.toml >/dev/null <<'EOF' [clusters.my-app] protocol = "http" load_balancing = "ROUND_ROBIN" frontends = [ { address = "0.0.0.0:80", hostname = "app.example.com" }, ] backends = [ { address = "10.0.0.10:8080", backend_id = "app-1" }, ] EOF
sudo systemctl reload sozuSozu re-reads the configuration and applies the new routing on the running proxy. Add more backends to the backends array for load balancing. Choose the algorithm with load_balancing (ROUND_ROBIN, RANDOM, LEAST_LOADED, POWER_OF_TWO).
Reconfigure a live proxy at runtime with the CLI
Sozu's signature feature is hot reconfiguration: add clusters, frontends and backends to a running proxy over the command socket, with no restart and no dropped connections. For example, add a cluster and a backend at runtime:
sudo sozu -c /etc/sozu/config.toml cluster add --id runtime-app --load-balancing-policy round_robin
sudo sozu -c /etc/sozu/config.toml frontend http add --address 0.0.0.0:80 --hostname runtime.example.com id runtime-app
sudo sozu -c /etc/sozu/config.toml backend add --id runtime-app --backend-id b1 --address 10.0.0.20:8080
sudo sozu -c /etc/sozu/config.toml frontend listTo persist runtime changes across restarts, save the live state with sudo sozu -c /etc/sozu/config.toml state save -f /etc/sozu/state.json. Then set saved_state = "./state.json" in the config.
Enable HTTPS for your own domain
The image ships a per-VM self-signed certificate, so HTTPS works out of the box for testing. For public traffic, install your CA-issued certificate and key. Reference them from the HTTPS listener (or a specific HTTPS frontend) in /etc/sozu/config.toml, and reload.
Replace the paths with your own PEM files:
sudo install -o root -g sozu -m 0640 /path/to/your-cert.pem /etc/sozu/tls/cert.pem
sudo install -o root -g sozu -m 0640 /path/to/your-key.pem /etc/sozu/tls/key.pem
sudo systemctl reload sozuSecurity recommendations
- Restrict the NSG. Allow TCP 80/443 only from the networks that should reach the proxy, and TCP 22 for administration only.
- Keep the command channel local. The Sozu command socket ships as a local Unix socket. Never point it at a TCP address. Administer over SSH with the
sozuCLI. - Use your own TLS certificate for public traffic. The per-VM certificate is self-signed for out-of-the-box testing. Install a CA-issued certificate for public traffic.
- Scope your frontends. Route only the hostnames you serve. A frontend only matches requests whose
Hostheader equals itshostname. - Keep the OS patched. Unattended security upgrades remain enabled on the running VM.
Support and Licensing
Sozu is developed by the Sozu project (Clever Cloud and contributors) and distributed under the GNU Affero General Public License v3.0 (AGPL-3.0). The full licence text ships on the image at /usr/share/doc/sozu/LICENSE.
This SecureAnyCloud image installs the unmodified upstream Sozu 2.2.0. SecureAnyCloud provides the packaging, the secure default configuration, the per-VM TLS automation, security patching, and 24/7 support with a guaranteed 24 hour response SLA.
SecureAnyCloud is not affiliated with or endorsed by the Sozu project. Sozu is a mark of its respective owner and is used here only to identify the software.
Deploy on Azure
Find Sozu HTTP Reverse Proxy / Load Balancer on Ubuntu 24.04 LTS on the Azure Marketplace, published by SecureAnyCloud. Deploy from the Portal or the Azure CLI as shown above.
Need Help?
Email sales@secureanycloud.com for deployment help, configuration questions, or licensing enquiries.
Deploy on Azure
Launch Sozu 2.2.0 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