Warpgate

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting size.

Configure the network security group (NSG) to allow these inbound ports:

• 22/tcp from your management network (this VM's own OS SSH)
• 443/tcp for the admin console and HTTPS targets
• 2222/tcp for Warpgate's own SSH bastion gateway
• 33306/tcp and 55432/tcp if you plan to add MySQL or PostgreSQL targets

Keep :2222 and :22 separate in your NSG and firewall documentation. They are two different listeners on two different processes.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Warpgate by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22).

Review the dedicated data disk on the Disks tab, then select Review + create and Create. After creation, add inbound NSG rules for 443 (admin console), 2222 (Warpgate's SSH bastion gateway), and 33306 and 55432 if you need the MySQL or PostgreSQL proxies.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:warpgate-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name warpgate \
  --image sac1647283583153:warpgate-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name warpgate --port 443 --priority 1010
az vm open-port --resource-group <your-rg> --name warpgate --port 2222 --priority 1020

Step 3 - Connect to your VM

Connect to the VM over SSH.

ssh azureuser@<vm-public-ip>

This is the VM's own OS management SSH on port 22. It is separate from the Warpgate bastion gateway that you configure later in this guide.

Step 4 - Confirm the services are running

Check that both services are active:

systemctl is-active warpgate.service nginx.service

Both report active. Warpgate listens natively, with its own TLS certificate, on these ports:

• :443 for the admin console and HTTPS targets
• :2222 for its SSH bastion gateway
• :33306 and :55432 for the MySQL and PostgreSQL wire proxies

nginx serves only an unauthenticated health check and a redirect on :80. Warpgate's audit database, session recordings, TLS certificate and SSH host and client keys live on the dedicated Azure data disk mounted at /var/lib/warpgate.

Step 5 - Retrieve your admin password

Your VM generates a unique admin password on first boot and writes it to a root-only file. The file also records the Warpgate version, the config file location and confirmation that a fresh TLS certificate and SSH keys were generated for this VM. Read it with sudo:

sudo cat /root/warpgate-credentials.txt

The file contains WARPGATE_ADMIN_USERNAME, WARPGATE_ADMIN_PASSWORD, the WARPGATE_URL to open in a browser, and the bastion and proxy ports. The password is only ever hashed (argon2id) inside Warpgate's own database, and no plaintext password ships in the image.

If WARPGATE_URL shows a private IP (an Azure Instance Metadata Service quirk on Standard SKU public IPs), use the VM's public IP address from the Azure Portal or az vm list-ip-addresses instead. The admin console works identically either way. Store the password somewhere safe.

Step 6 - Confirm the health endpoint and the login round-trip

nginx serves an unauthenticated health endpoint for load balancers and probes. Warpgate also ships its own healthcheck subcommand. Run both:

curl -s http://localhost/healthz
sudo warpgate --config /etc/warpgate.yaml healthcheck && echo "admin console healthy"

Because a password is set on first boot, the login API rejects a wrong password and accepts only the per-VM one. Nobody reaches the console or your recorded sessions without it. Test both cases:

PW=$(sudo grep '^WARPGATE_ADMIN_PASSWORD=' /root/warpgate-credentials.txt | cut -d= -f2-)
curl -sk -o /dev/null -w 'wrong password -> HTTP %{http_code}\n' -X POST -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"wrong-pw"}' https://127.0.0.1/@warpgate/api/auth/login
curl -sk -o /dev/null -w 'per-VM password -> HTTP %{http_code}\n' -X POST -H 'Content-Type: application/json' \
  -d "{\"username\":\"admin\",\"password\":\"$PW\"}" https://127.0.0.1/@warpgate/api/auth/login

The wrong password prints HTTP 401; the correct one prints HTTP 201.

Step 7 - Sign in to the web console

Browse to https://<vm-public-ip>/. The TLS certificate is self-signed per VM, so accept the browser warning until you add a trusted domain and certificate (see Maintenance).

On the Welcome screen, enter admin and the password from Step 5.

Step 8 - The Sessions dashboard

After you sign in, you land on the Sessions dashboard. It shows a "getting started" checklist (check the docs, add a target, add a non-admin user) and the list of active sessions.

Every connection through Warpgate, including your own admin login, appears here in real time with its protocol, user and age.

Step 9 - Add your first target

Open Config > Targets > Add a target. Warpgate supports five target types: SSH (shell, SFTP and port forwarding), HTTP (Warpgate acts as a reverse proxy), MySQL, PostgreSQL and Kubernetes (experimental).

Pick the type that matches the server or service you want your team to reach through the gateway. Then fill in its host, port and credentials.

Once a target exists, create an Access role and assign it to the target and to the users who should reach it. Your users then connect through the gateway. For example, for an SSH target:

ssh -p 2222 <your-warpgate-username>:<target-name>@<this-host>

Step 10 - Browse a recorded session

Select any session in the Sessions list to open its detail view. It shows a timestamped, searchable log of every request Warpgate proxied for that session, plus a Close now control to terminate the session immediately.

This is the audit trail that makes Warpgate useful for compliance and incident response. Every SSH, HTTP or database session your team makes through the gateway is recorded here.

Step 11 - Confirm data lives on the dedicated disk

Warpgate keeps its audit database, session recordings, TLS certificate and SSH host and client keys under /var/lib/warpgate on the dedicated Azure data disk. They survive OS changes, and you can resize the disk independently. Confirm the mount:

findmnt /var/lib/warpgate

A separate Azure data disk backs the mount. The disk is captured into the image and re-provisioned on every VM.

Maintenance

• Password: the admin password is set on first boot and stored only as a hash inside Warpgate's own database. To reset it, run sudo warpgate --config /etc/warpgate.yaml recover-access (interactive) from an SSH session.
• TLS: the admin console's certificate is self-signed per VM. For production, add a trusted domain and a certificate you control from Config > Targets (Warpgate's HTTP target and reverse-proxy TLS settings), or place a certificate in front of :443 on your own domain.
• Users and roles: create separate non-admin accounts under Config > Users. Scope what each can reach with Access roles, so day-to-day users never need the admin account.
• Ports: the SSH bastion gateway (:2222), MySQL proxy (:33306) and PostgreSQL proxy (:55432) are Warpgate's own listeners, independent of this VM's OS SSH (:22). Open only the ports you use in your NSG.
• Upgrades: Warpgate is a single binary at /usr/bin/warpgate. To upgrade, download a newer pinned release, verify its checksum, replace the binary and run sudo systemctl restart warpgate. Your audit database, recordings and certificate under /var/lib/warpgate are preserved.
• Storage: all Warpgate state lives under /var/lib/warpgate on the data disk. Back up that volume to protect your audit trail and session recordings.
• Security patches: unattended-upgrades stays enabled, so the OS keeps receiving security updates automatically.

Support

SecureAnyCloud provides 24/7 support for this image. For questions about Warpgate or help with your deployment, contact sales@secureanycloud.com.

Deploy on Azure

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