Deploying Portward in your Azure subscription

For the person who looks after Azure at your company. About 20 minutes, and nobody from Portward is involved. At the end, your team can ask Claude or ChatGPT about company data through a gateway that runs in your own subscription. The gateway swaps the values you mark as sensitive for tokens before the AI sees them, and records every answer in your subscription. Portward (the company) never receives your data.

What gets created

Everything lands in one resource group you choose, and all of it belongs to you:

Resource	What it’s for
A small Linux VM (portward)	Runs the gateway with Docker. 2 vCPU / 1 GiB by default. Ubuntu’s security updates install themselves; gateway updates are one command (Update and back up).
A records disk (portward-records)	Answer records, setup, and the encrypted list of connections. Encrypted at rest. It’s kept if the VM is deleted.
A Key Vault (pw-…)	Every secret: your sign-in app’s secret, your Portward license key, and the gateway key, which the VM generates on its first start. Only the VM’s network can reach it.
A storage account (pwbackup…)	A copy of the records every night, kept 30 days by default. The VM writes it with its own identity; no account keys are used.
A network, a public IP and a firewall (NSG)	With the relay, nothing is open inbound: the public IP is only for going out. With your own domain, only ports 80 and 443 are open. SSH is never open.
An identity (portward-gateway)	Lets the VM read its secrets and write its backups, and nothing else.

Roughly $14 a month at the default size (B2ats_v2) and Azure’s list prices: about $7 for the VM, $4 for the public IP, $3 for the disks, and a few cents for the vault and backups.

Before you start (10 minutes)

1. Register the sign-in app in your directory. The steps for Microsoft Entra, Okta and Google Workspace are in Sign-in setup. In short, for Entra:
   • Go to Entra admin center → App registrations → New registration, name it Portward, and choose this organizational directory only.
   • Set the redirect URI (type Web) to https://<the gateway's address>/auth/callback.
   • Copy the Application (client) ID.
   • Create a client secret under Certificates & secrets and copy its Value.
   • Under Token configuration, add a groups claim (Groups assigned to the application).
   • Assign the app to the groups that should use Portward.
   • Copy the Object ID of the group whose members will manage Portward. That’s your admin group.
2. Decide how Claude and ChatGPT will reach the gateway. They connect from the internet, so the gateway needs a public address. Pick one:
   • The Portward relay (recommended). Your address is <name>.gw.portward.ai. Signup picks the name from your email’s domain, and it is in your license key. The gateway connects out to the relay, nothing opens inbound, and there’s no DNS to set up. The relay passes traffic through still encrypted: the certificate and its key stay on your VM.
   • Your own domain, such as portward.yourcompany.com. The VM gets ports 80 and 443 open, and you create one DNS record after deployment. You need a name you control. Azure’s own *.cloudapp.azure.com names don’t work.
3. Have your license key (pwlic_…) from the key page (Get started, step 2). The gateway uses it to download its image and to connect to the relay.

Deploy (5 minutes, then about 5 minutes to start)

Press Deploy to Azure (also on the page that showed your license key). The portal opens Portward’s own wizard in your subscription. Nothing is created until you select Create. The template and wizard files, mainTemplate.json and createUiDefinition.json, are also at https://portward-launch.s3.us-east-2.amazonaws.com/templates/1.1.1/azure/. Fill in the wizard:

Step	What to enter
Basics	Subscription, a new resource group, and the region closest to your databases.
Sign-in	Your directory’s sign-in address (prefilled for your Entra tenant), the app’s client id and secret, and the admin group.
Address	Your license key (paste it here; it is never part of the link), then Portward relay (no inbound ports), where the address comes from the key, or My own domain (ports 80 and 443) plus the name. The wizard shows the exact redirect address your sign-in app needs.
Machine	Size, administrator user name, and an SSH key (let the portal generate one; you’ll rarely need it). The records disk (8 GiB) and daily backups kept 30 days are the defaults.
Image	Leave the image as it is: it is pulled with your license key. Keep Protect the Key Vault from purge on unless this is a test: it can’t be turned off later.

Select Create. When the deployment finishes, the VM sets itself up: it installs Docker, creates the gateway key in your Key Vault, and starts the gateway. That takes about five minutes.

The deployment’s Outputs tab lists:

• dataConnector and adminConnector: the two addresses to add in Claude or ChatGPT.
• signInRedirect: what your sign-in app’s redirect URI must be.
• dnsTarget: with your own domain, the record to create. Use a CNAME to the …cloudapp.azure.com name, or an A record to the IP. Caddy, on the VM, gets the HTTPS certificate within a minute of the name resolving.

Check it

Open https://<the gateway's address>/health in a browser. It should answer "ok": true. For the full check, run the gateway’s own doctor: in the portal, open VM → Run command → RunShellScript and run portward-azure doctor. It checks the certificate, your directory, both connectors’ sign-in, and the records, and says what to fix.

Make yourself the admin, connect your data, give your team access

1. Add the adminConnector output in Claude or ChatGPT as a custom connector (Get started, step 7) and sign in with your work account. Members of the admin group are admins at once.
2. For databases inside your network: the VM sits in its own network, portward-vnet (10.40.0.0/24). Peer it with the network your databases are in, or deploy into a subscription that can reach them.
3. Say which database hosts admins may connect, and who may use the data connector, in the gateway’s settings on the VM. In the portal, open VM → Run command → RunShellScript and run, with your own values:

   cd /var/lib/portward/install
   sed -i 's/^setup_hosts = .*/setup_hosts = ["db.internal.yourcompany.com"]/' portward.toml
   sed -i 's/^user_groups = .*/user_groups = ["<group object id>"]/' portward.toml
   docker compose restart gateway

   setup_hosts takes exact host names, or "*.corp.yourcompany.com" for a whole domain. Azure Blob Storage, Amazon S3, Microsoft 365 and Google Drive need no entry. A custom storage endpoint does. user_groups takes the Object IDs of the Entra groups whose members may ask questions.
4. From the admin connector, set up the connection and choose what the AI may see: Get started, step 8.
5. Everyone in those groups adds the dataConnector output in Claude or ChatGPT: Get started, step 9.

Running it

• Settings are in /var/lib/portward/install/portward.toml on the VM, on the records disk. Use Run command to edit it (for example setup_hosts, users, user_groups), then run cd /var/lib/portward/install && docker compose restart gateway.
• Update, back up and restore: Update and back up. Updates run through Run command, portward-azure update. The gateway key is in the Key Vault as portward-key. Never delete it: without it, saved connections can’t be opened.
• Logs: cd /var/lib/portward/install && docker compose logs gateway. A refused sign-in names the person’s id. The VM’s start-up log is in journalctl -u portward.
• Rotating secrets: put the new value in the Key Vault (directory-secret or license-key, after a key is reissued) and restart the VM, or run systemctl restart portward. Secrets live only in memory on the VM and are read again at every start. To change them yourself, give your own account the Key Vault Secrets Officer role and allow your IP in the vault’s firewall.
• Removing it: delete the resource group. The Key Vault stays recoverable for 90 days; with purge protection on, it can’t be purged early.

If something’s wrong

What you see	What to do
/health doesn’t answer after 10 minutes	Run journalctl -u portward through Run command. “Key Vault answered … waiting for access” is normal while Azure applies the identity’s access to the vault. Portward’s start-up on the VM tries again every 15 seconds, for up to 10 minutes. If it then logs “can’t read … from Key Vault”, check that the identity portward-gateway has Key Vault Secrets Officer on the vault.
A certificate error on your own domain	Check that the DNS record points at dnsTarget, and that nothing in front of the VM blocks ports 80 and 443.
A certificate error on the relay	Check the license key in the Key Vault (license-key) is current, then systemctl restart portward. Run docker compose logs relay to see the relay connection.
Sign-in says the redirect address doesn’t match	Your sign-in app’s redirect URI must be exactly the signInRedirect output.
The image doesn’t pull	The license key in license-key was replaced, revoked, or the trial ended. Put the current key there. Replace the license key, or extend the trial.