Expose

Search the Marketplace for Expose on Ubuntu 24.04 and choose your VM size.

Attach an NSG that allows TCP 22 (SSH) from your management network and TCP 443 (dashboard and tunnel traffic) from the internet. Tunnel traffic must reach the VM from wherever your public URLs are consumed, so 443 generally needs to be open broadly. Port 80 only issues an HTTPS redirect and serves the health probe.

Run the following on your own workstation, where the Azure CLI is installed:

az vm image terms accept --urn sac1647283583153:expose-ubuntu-24-04:default:latest
az vm create \
  --resource-group my-resource-group \
  --name my-expose-vm \
  --image sac1647283583153:expose-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
# Open the ports the appliance uses
az vm open-port --resource-group my-resource-group --name my-expose-vm --port 443 --priority 1001
az vm open-port --resource-group my-resource-group --name my-expose-vm --port 80 --priority 1002

ssh azureuser@<vm-ip>

First boot generates your credentials and renders the nginx site before the tunnel server starts, so give the VM a few seconds after it boots. Check the services:

systemctl is-active expose-server nginx expose-firstboot

Expected output:

active active active

For a fuller view of the tunnel server, run:

systemctl status expose-server --no-pager | head -12

The health probe answers without credentials, so a load balancer can watch it:

curl -s http://127.0.0.1/healthz

Expected output:

ok

Every VM generates its own dashboard password and tunnel token on first boot and writes them to a root-only file:

sudo cat /root/expose-info.txt

EXPOSE_ADMIN_PASSWORD signs you in to the dashboard. EXPOSE_AUTH_TOKEN is what an Expose client presents to open a tunnel. Treat both as secrets. No two VMs share them, and neither is baked into the image.

Confirm that the tunnel server answers through the TLS front door:

curl -k -s -o /dev/null -w "%{http_code}\n" https://127.0.0.1/api/health

Expected output:

200

Expose routes purely on the hostname of the incoming request. A tunnel published as demo is served at demo.your-domain.com. To use your own domain, add two DNS records that point at the VM's public IP:

your-domain.com A <your-vm-ip> *.your-domain.com A <your-vm-ip>

The wildcard record lets every new tunnel get its own hostname without adding DNS each time. Then set the domain on the VM and re-render the certificate and nginx site:

sudo sed -i 's|^EXPOSE_DOMAIN=.*|EXPOSE_DOMAIN="your-domain.com"|' /etc/expose/expose.env
sudo /opt/expose/render-tls.sh
sudo /opt/expose/render-nginx.sh
sudo systemctl reload nginx
sudo systemctl restart expose-server

Until you do this, the tunnel domain defaults to the VM's own address. That is enough to reach the dashboard but not to serve tunnel subdomains. /etc/expose/README.txt on the VM repeats these steps.

Browse to https://<your-vm-ip>/ and sign in with the user admin and the EXPOSE_ADMIN_PASSWORD from Step 5. The dashboard is reachable by IP even before you configure DNS, because the appliance's nginx front door routes the VM's own address to the admin interface.

The Users page is where tunnel access tokens live. Your per-VM token is already registered there as sac-default.

The Settings page shows the security posture this image ships with. Require authentication tokens is enabled, so the server accepts a tunnel only from a client presenting a valid token.

Your browser trusts only the per-VM self-signed certificate at this point, so you will see a certificate warning until you complete Step 10.

On your own workstation, not the VM, install the Expose client and point it at your server. The client is a single file:

curl -Ls https://github.com/exposedev/expose/releases/latest/download/expose -o expose chmod +x expose ./expose token <auth-token> ./expose share http://localhost:3000 --server-host=your-domain.com --server-port=443 --subdomain=demo

Use the EXPOSE_AUTH_TOKEN from Step 5 as <auth-token>. The client prints the public URL it has been given.

Back in the dashboard, the Sites page now lists the live tunnel. It shows which local address the tunnel points at and which token opened it.

Anyone with the public URL now reaches the site running on your workstation. The page is served from a laptop, over a tunnel, through a server you own.

The admin API rejects anything without your per-VM credential. First, call it without credentials:

curl -k -s -o /dev/null -w "%{http_code}\n" https://127.0.0.1/api/users

Expected output:

401

Then call it with the per-VM password from Step 5:

curl -k -s -o /dev/null -w "%{http_code}\n" -u "admin:<admin-password>" https://127.0.0.1/api/users

Expected output:

200

The upstream project's published default login is rejected with 401. That credential does not exist on this image, and the expose-server service refuses to start if it is ever put back in place.

The image generates a self-signed certificate per VM, so the dashboard and tunnels are encrypted immediately. Once your DNS from Step 6 resolves, replace it with a publicly trusted wildcard certificate. A wildcard is required because every tunnel gets its own subdomain, and it must be issued with a DNS-01 challenge:

sudo snap install --classic certbot
sudo certbot certonly --manual --preferred-challenges dns \
  -d your-domain.com -d '*.your-domain.com'
sudo cp /etc/letsencrypt/live/your-domain.com/fullchain.pem /etc/expose/tls/expose.crt
sudo cp /etc/letsencrypt/live/your-domain.com/privkey.pem /etc/expose/tls/expose.key
sudo chown root:expose /etc/expose/tls/expose.crt /etc/expose/tls/expose.key
sudo chmod 0644 /etc/expose/tls/expose.crt
sudo chmod 0640 /etc/expose/tls/expose.key
sudo systemctl reload nginx