Releases and updates
How a new version reaches Proxara’s own service, and how signed releases reach an install in your own Azure.
Updated 2026-10-31
How a new version of Proxara reaches you depends on where it runs.
In Proxara’s AWS and Azure
Proxara ships each new version of its own service. The version serving keeps serving until the new one answers its health check, and a call already connected stays connected while it changes over.
In the lender’s own Azure
Everything that reaches the install from Proxara is a signed release. The install pulls it, checks it and runs it only if the check passes. Proxara never pushes anything in.
| Release | What it carries | How often |
|---|---|---|
| Application | The install’s own software, as signed container images | When Proxara publishes one, applied when the lender chooses |
| Rules | The agency rules the work follows, as code with their effective dates | Pulled hourly |
Each release is signed in Proxara’s build and verified inside the lender’s environment before anything in it runs. A release whose signature doesn’t verify is refused, and the install keeps running the release it has. An application release waits until the lender’s administrator applies it by running the same installer in place, and the previous release is one command away.
How an install’s release is built
- A software bill of materials: every release lists each component and version it contains, from the base image to the packages inside it. Ask for the current one.
- A vulnerability check: every release is checked against published security advisories. A release with a known vulnerability that has a fix published is stopped before it ships.
- A pinned model: the reading model’s version is pinned in the install and changes only with a release that names the new one.