One installer, run by your IT
What the installer checks before it creates anything, what it creates, and how an update arrives without anyone holding access.
Proxara is installed by the lender’s own administrator, with one command, in the lender’s own Azure subscription. Proxara is not on the call. It holds no credential, no role and no standing access, before the install or after it.
This post walks through that command: what it needs, what it checks before it creates anything, what it creates, how it knows that what it pulls is genuine, what it costs, and how the next version arrives.
What it needs
Three things decide the day. The first is GPU quota: the product runs on one serverless A100 profile in Azure Container Apps, and a quota request to Microsoft can take days, so it is the first thing to ask for. The second is one administrator, signed in to Azure CLI in the lender’s tenant, with Owner on the subscription or the resource group and the right to create an app registration in Entra. The third is the machine that runs the command: a Mac on Apple silicon, or Windows with a WSL2 Ubuntu distribution.
Proxara builds the lender’s package around six values the lender sends once: the subscription, the tenant, the resource group, a new storage account name, a new Key Vault name, and the people who will use the product. The package arrives with them inside, so nothing is edited by hand. Three things arrive separately and never sit inside the archive: the publisher’s public key, a limited registry pull token and a read-only token for the rule feed.
The same package also runs on a GPU server the lender prepares inside its own firewall.
What it checks before it creates anything
The first run is offline. It verifies the package’s signature against the publisher’s key, builds a private Python environment for itself and reports that the package is ready and that nothing in the cloud was changed. It installs nothing machine-wide.
The install then checks the directory: that the tenant matches the package and that every person named exists. Those checks only read. Then it checks the account, each item a named check with its own result: the region, the A100 quota, the installer’s own permissions, the lender’s network policy and the licence notices. The empty Container Apps environment and its GPU profile are made first, because the quota can only be read from inside one. A check that fails stops the run there and names itself, and nothing else is created.
What it creates, in the lender’s name
Everything lands in the lender’s resource group, under the lender’s subscription: one container app on one A100, with no automatic scale-out; an encrypted storage account with separate shares for the model, the configuration, the rules, the working files and the results; a Key Vault with purge protection that holds every secret; a managed identity scoped to what the app reads; one single-tenant sign-in registration in Entra with two roles; and an Automation account that wakes the compute in the morning and stops it at night.
It creates no registry, database, cache, Kubernetes cluster, gateway, firewall or second GPU of its own. The resources are declared as Bicep, so the lender’s security team can read each one before the command runs.
Each stage prints its name as it is reached and leaves a receipt. If one stops, the receipt says where, and the recovery command picks up from it. The installer never creates a resource twice and never repeats a write whose outcome it does not know.
Everything it pulls is signed
Three things come in from Proxara’s side: the application image, the model and the rules. Each is signed, and each is checked inside the lender’s environment before it is used.
The image is pulled from the publisher’s registry with the limited token, and its signature is verified. The model’s files, 17.39 GB, stream from the pinned source straight into the lender’s own share, and each file’s size and hash are checked against the signed manifest before it is moved into place. The rule release is verified with an independent public key and is bound to the exact application image it was signed for, so a rule release can never run on an image it was not made for.
When the application starts, all seven components are checked, ownership is confirmed a second time, a report is saved, and the live address is printed last.
What it costs, printed first
The A100 bills by the second while it is awake, about USD 2.16 an hour, and nothing while it is stopped except storage. The compute runs 06:00 to 20:00 Eastern every day. The lender’s own Automation account wakes it and stops it, and unfinished work is checkpointed before the stop and resumed after the start.
Preflight prints the quote for the lender’s subscription at current retail prices before the application is running: about USD 992 a month on the 06:00 to 20:00 window, about USD 1,126 to 22:00, and, for comparison, about USD 1,663 always on, each with storage, logs and the schedules included, before tax. Anything still unknown, such as tax or a private endpoint the lender’s own network policy requires, is listed as unknown. A price above the lender’s target is printed as such; it never stops the install on its own.
How the next version arrives
A new version of the application is a new signed package. The administrator runs the same installer with update. It checkpoints the running work, stops the old revision, starts the new one, and confirms ownership and health before the old one is retired. Open loans and retained results survive the change. Budget an hour to an hour and a half; on the recorded runs the page was down for twenty to thirty minutes of it.
Rules move faster than that. The application reads the publisher’s signed rule feed every hour with its read-only token, verifies each release, activates it and recomputes the open loans it affects. The earlier result is kept beside the new one, so a rule change never rewrites what a loan officer has already seen.
Nobody at Proxara holds a key
After the install, no identity outside the lender’s tenant holds a role, and the security team can confirm that in a few minutes. Sign-in goes through the lender’s own Entra, and only the people the lender assigns a role can open the page.
Support works from what the lender chooses to send. A private health endpoint and a diagnostics bundle carry versions, timings, rule identifiers, error classes and health state, and never borrower text. The lender’s IT exports the bundle when support needs it, and nobody at Proxara can read it without them.
One command, run by the lender’s administrator, with the price on the screen before anything runs and every resource and key in the lender’s name from the first minute.


