Release LoadGen Api, Appliance and MCP Server: 1.0.0.12421

LoadGen General

• The LoadGen Core Agent is now available as a public Docker image, loadgen/loadgen-core-agent. The Core Agent can run as a container on any Linux Docker host, giving you a second way to add web test capacity alongside the Launcher Appliance. The first image packages Suite build 12411, the first .NET 10 Core Agent. Point it at your platform the same way you would any other Core Agent.

LoadGen Api

• Credential profiles now record when their secret expires and which account they belong to. A profile gains an expiry date, a note of where that date came from (entered by hand, detected from the token itself, or issued by the platform), and the identity the credential was issued for. An empty expiry means the date isn't known rather than that the credential never expires. Expiring credentials raise reminders in the Reminders hub, so a long-lived personal access token no longer runs out unannounced.

• Repository health: a new check type that scans your repositories and reports outdated packages, known vulnerabilities and end-of-life runtimes. One check can cover an Azure DevOps organization or project, a GitHub organization or user, or a GitLab group — the endpoint you give it is the scope. The check catalog gains three entries under a new DevOps/Repositories group, one per provider, each carrying the credential types that provider accepts and a scan cadence suited to the work. Because a scan is long-running, triggering one is accepted for background execution rather than answered inline.

• Uptime check import: validate a JSON document of checks, then import them in one go. Every inline password and key found in the document is moved into Credential Manager rather than stored on the check. Checks reference their datasource, credentials, groups and tags by name, so a file moves cleanly between appliances. The API also generates the JSON Schema and both an Empty and an Example template for any check type, so the document shape never has to be written from memory. The import endpoints sit under the existing Uptime Monitoring - Checks tag and follow the same permissions as the checks themselves.

• LoadGen AI Credits (LG064): run LoadGen's AI features on prepaid credits instead of your own AI provider key. Making a LoadGen Cloud profile your default AI provider routes every existing AI panel — SessionSight summaries, Monitoring and Dashboard analytics, Uptime AI analysis, API Testing analytics and flow generation, and Analyse workload analysis — through LoadGen Cloud on prepaid credits. There is no API key to manage on this provider type; the model is chosen as a tier, with a default effort level per profile. A new Config - AI Credits area reports licence state, connection state, gateway reachability and your credit balance, so the frontend can tell "not licensed" apart from "not yet connected". Long answers stream internally so that a lengthy analysis can't be cut short in transit, and a prompt-size cap keeps a single click from spending an unexpected amount of credit. Networking: the appliance reaches the AI gateway at ai.loadgen.cloud over HTTPS — allow it outbound if you intend to use AI Credits. LG064 is licensed per tenant and does not bind to a machine.

• Fixed Global Variables being two disconnected stores: variables entered on the setup page were held separately from the store the agents actually read, so nothing defined there ever reached a test, and a variable an agent set never appeared on the page. Both sides now read and write one store, matching what the page has always promised.

• Fixed the uptime check-type catalog failing to load entirely, with clients reporting The JSON value could not be converted to System.Int32. Catalog entries that take the general interval or timeout no longer publish those defaults in a shape that costs the client every other entry in the list.

• [#9618] Fixed uptime analytics reporting a capped total rather than a measurement of the requested period. The uptime-percentage and response-time endpoints computed every figure from an in-memory buffer holding the newest 1,000 results per check, so any window longer than that buffer covered — for a one-minute check, anything past about 17 hours — came back describing the buffer instead of the period, with the passed and failed counts summing to exactly 1,000. Both endpoints now read the datasource for the whole window. Where a datasource cannot be reached, the response carries a warning saying the figures may be short instead of presenting buffer contents as a full-period result.

• Fixed Service Levels rejecting every objective created after the first with a 500, and no objective's version history being readable. Objective versions were written in a layout the reader could not parse back, so the first create succeeded only because the file did not yet exist. Existing files are read correctly going forward.

• Fixed creating a Wait Event, a Performance Counter Settings entry or a configuration backup schedule saving the row and then answering 500, leaving the dialog open and the new row visible only after a page reload. All three now answer with a proper 201 and the location of the created record.

• Fixed credential migration linking an uptime check to an existing credential profile on a name match alone, which could leave a migrated check using a credential that did not belong to it, or with no usable authentication. A check is only linked to an existing profile when the profile's type and stored secret match as well; otherwise a distinct profile is created. Worth checking after upgrading: if you have already run the credential migration, review uptime checks whose report line read reused — any that began failing straight after migration are the ones this affected.

• Fixed credential migration reporting a Run-as profile as already migrated when a profile of a different type happened to hold the same name, so it never reached Credential Profiles at all. Nothing broke at run time — agents resolve Run-as profiles through the legacy store either way — but the migration's own bookkeeping was wrong, and re-running it did not correct it. Matching now takes the profile type into account.

• Fixed Omnissa Horizon VB.NET workloads being dispatched to the agent as C#, so the in-session Local Client compiled VB source with the C# compiler and the run died in a storm of compiler errors; setting the script language to C# was the only workaround. Horizon workloads now dispatch with the language actually configured. Requires an API redeploy to take effect; no agent-side change is needed.

• Fixed 18 controller tags being absent from the Swagger tag order and sinking to the bottom of every Swagger document regardless of the section they belong to — among them Infrastructure - Launcher Appliance, Config - Backup, Configuration - Credential Profiles, Monitoring - Dashboard, the Uptime Monitoring catalog, heartbeat, reminders and scripts tags, Insight - Analytics and Master - Enrollment. Each now renders in its proper section.

LoadGen Appliance

• [#9552] Offline update bundle — update a whole air-gapped appliance from one signed artefact, host packages included. An appliance with no route to the internet could already be updated one component at a time, but it had no way to know what to update to, no way to get any of it verified, no way to update its vendor images or its operating system at all, and no way to survive an interruption partway through. This release adds the missing half: one bundle per release set, signed by the release pipeline's own Azure Trusted Signing identity, and one recoverable transaction on the appliance that applies it — the agent, the host packages, every container image, the binary archive and the release catalog — and issues a receipt stating exactly what landed. The appliance verifies the signature against the release identity it trusts before anything is applied, importing the bundle's catalog also gives a never-connected appliance real update information on its tiles for the first time, and an interrupted transaction can be resumed or cancelled rather than leaving the appliance half-updated.

• Fixed Update all moving a component backwards to match a release set. The four release groups advance independently, so a stable set routinely names suite and insight builds that an appliance has already passed — applying the set exactly then made one button upgrade some components and downgrade others, with no way to take one half without the other. Applying a release set is now monotonic: it means bring every component up to at least this set, and anything the set would downgrade is held at its current build.

LoadGen Launcher Appliance

• [#9616] Fixed the Package drift card on the appliance detail page rendering a stored inventory that only advanced on the appliance's own heartbeat, so an appliance that had just been rebooted could still show Reboot required long after the platform held a correct inventory. The refresh call now writes the fresh snapshot the appliance agent returns through to the stores the drift panel reads, instead of discarding an answer it already had in hand.

LoadGen MCP Server

• Fixed the set_variable, delete_variable and clear_all_variables tools writing to a store that no test ever read — the same defect as the Global Variables page, and fixed by the same change. Variables set through these tools now reach the agents.

• [#9618] The uptime analysis tools are corrected by the same change as the uptime analytics endpoints: results now cover the whole requested period instead of the newest 1,000 results per check.

• The five variable tool descriptions now state which store each one means. list_variables and get_variable read the MCP server's own environment, while set_variable, delete_variable and clear_all_variables read and write test-run globals — so get_variable does not read back what set_variable wrote. The tool names are unchanged in this release.