October 2026: Feature releases & highlights

Enhanced tenant bootstrapping, Avassa Cloud Platform approvals, Billing metrics, GPU metrics

• Enhanced tenant bootstrapping: New tenant root users now get a one-time set-password link (valid for 1 hour, 1 day, or 7 days) and choose their own password, so administrators no longer have to share passwords over email or chat.
• Avassa Cloud Platform members and approvals: ACP now supports multiple members with Viewer, Billing admin, and Owner roles, and you can require a second approver for sensitive operations such as deleting an environment.
• Billing metrics in Avassa Cloud Platform: A new Billing section shows your usage per Control Tower in real time, with trends and CSV export, so you no longer have to wait for the invoice to understand your costs.
• GPU metrics for NVIDIA hosts: Hosts with NVIDIA GPUs now report utilization, memory, temperature, power, clocks, and throttling in the host metrics topic, so you can monitor GPUs across the whole fleet without logging in to individual hosts.

Enhanced bootstrapping of tenants

Creating a tenant and handing it over to its first user is now simpler and more secure. Previously, the administrator creating the tenant had to choose a password for the tenant’s root user and pass it on, which meant the password was shared over email or chat and known by more than one person. Now the tenant root user gets a one-time set-password link and chooses their own password, so no password passes through the administrator.
When you create a tenant, enter the root user’s username and full name, and under Initial password, select Create a set-password link. You can choose how long the link is valid: 1 hour, 1 day, or 7 days. Set password now is still available if you prefer to set the password yourself.

After you create the tenant, the summary shows the set-password link, the tenant root token, the Control Tower web UI login URL, and the supctl install instructions. The link appears only once and can be used only once before it expires. Use Copy non-secret summary to clipboard to send the onboarding details, including the password link, to the new user. The tenant root token is not part of the summary and can be saved in a vault.

Avassa Cloud Platform: Members and Approvals

Some Avassa users may not be familiar with the Avassa Cloud Platform (ACP), the portal your organization uses to create and delete environments. An environment consists of a single Control Tower and its associated edge sites. For example, you might have separate production and test environments, or run different Control Towers for different geographic regions.
In earlier releases, ACP had a single user with full permissions.
We’ve enhanced user management so the original user can invite new members to ACP. Each member can be assigned a different role, and you can apply approval processes to operations—for example, requiring at least two members to approve the deletion of an environment.

As shown to the right, ACP supports the following roles:

• Viewer: can read information about environments, ACP members, and billing metrics.
• Billing admin: relevant for on-premises Control Towers; this role can upload billing metrics exported from the Control Tower (see Billing Metrics below).
• Owner: has full rights.
• Approver: can approve operations requested by other members, but never their own. You can assign Approver as a dedicated role or combine it with any of the other roles.

To require approvals for operations in ACP, contact our support channel. Once approvals are enabled, you can safeguard every operation with an approval step.

For example, adding a new member as an approver:

Results in:

The Approvals section in ACP lists all ongoing and past approval events:

As has been possible for several releases, you can choose which AWS region the Control Tower runs in when creating a new environment:

Now suppose you want to delete this environment. Because approvals are enabled, you cannot do this on your own; another team member must approve it:

All other approvers receive an email with the request and can approve the operation after logging in to ACP.

With members, roles, and approvals, ACP fits the way your organization actually works:

• No more shared credentials: each person logs in with their own account, so you always know who did what, and you can revoke access for one person without affecting anyone else.
  Least privilege by default: give each member only the rights they need. Finance can work with billing metrics, auditors and stakeholders can view environments, and only owners can make changes.
• Protection against costly mistakes: requiring a second approver before operations such as deleting an environment means no single person, or compromised account, can take down production on their own.
• A clear audit trail: the Approvals section records every ongoing and past approval, making it easy to review changes and demonstrate compliance.
  To get started, invite your colleagues to ACP and assign them roles. To enable approvals, contact our support channel.

Billing Metrics in Avassa Cloud Platform

Avassa pricing is based on peak usage each month. Each Control Tower carries its own fee, and all usage metrics are measured per Control Tower. The primary billing metrics are:

• Tenant application sites: The tenant site fee applies to every tenant site that has one or more applications deployed. Assigned sites with no applications deployed are not subject to the tenant site fee.
• Number of hosts: Usage is based on the monthly peak number of hosts managed by a Control Tower. The underlying metric counts initialized Edge Enforcers.
• Replica secrets: A fee applies for storing secrets (key/value pairs such as keys, tokens, and credentials) in Strongbox.
• Tenant streaming sites: Usage is based on the monthly peak number of tenant sites using Volga. Only topics created by the tenant are billed; Avassa built-in topics cost nothing.

ACP now includes a new Billing section where you can view your billing metrics:

You can filter the view by period, metric, and Control Tower (environment).
For a more detailed view, drill down into Usage & trends. You can also export the data as a CSV file for your own cost calculations and allocations.
In summary, you no longer have to wait for your invoice to understand your costs. Billing metrics that were previously visible only on your bill are now available in ACP in real time, so you can track usage per Control Tower, spot trends early, and plan ahead.

GPU metrics for NVIDIA hosts

Hosts with NVIDIA GPUs now report GPU metrics in the host metrics topic. The data comes from the NVIDIA driver, the same source nvidia-smi reads, so you can watch GPU load, memory pressure, temperature, and power across your whole fleet without logging into individual hosts.

Each GPU on a host appears in a new gpus array, identified by its UUID:

gpus": [
    {
      "id": "GPU-4d92bb59-9bb3-6d24-d714-106c3f8b14c0",
      "utilization": 2,
      "memory-bandwidth-utilization": 0,
      "memory-total": 17094934528,
      "memory-used": 10861740032,
      "memory-free": 5749538816,
      "temperature": 51,
      "power": 33498,
      "power-limit": 150000,
      "clock-sm": 1860,
      "clock-memory": 14001,
      "performance-state": 0,
      "throttle-reasons": "",
      "processes": 2
    }
  ]

Field	Description	nvidia-smi equivalent
utilization	Percentage of time during which one or more kernels were executing on the GPU.	GPU-Util
memory-bandwidth-utilization	Percentage of time during which GPU memory was being read or	— (nvidia-smi -q)
memory-total / -used / -free	GPU memory (bytes)	Memory-Usage
temperature	Core temperature (°C)	Temp
power / power-limit	Current draw and cap (milliwatts)	Pwr:Usage/Cap
clock-sm / clock-memory	Streaming multiprocessor clock frequency in MHz.	— (nvidia-smi -q -d CLOCK)
performance-state	The performance state of the GPU, where 0 is maximum performance, and 15 is minimum performance.	Perf (P0)
throttle-reasons	Why the GPU clocks are currently below their maximum. No bits setmeans nothing is holding the clocks back; the leaf is absent whenthe driver could not be asked. The positions match NVML’s clock event reason mask, so each bit indicates the reason NVML documents at that position.	— (nvidia-smi -q -d PERFORMANCE)
processes	The number of processes holding a compute context on the GPU. Zero means no application is computing on the GPU. Processes that use the GPU only for graphics are not counted.	Processes table

Typical uses are spotting GPUs that are maxed out or sitting idle, catching thermal or power throttling before it hurts inference latency, and confirming that a newly deployed AI workload actually landed on the GPU.

AI started on two gaming cards

In 2012, a University of Toronto student named Alex Krizhevsky trained a neural network to recognize images, using two consumer GeForce GTX 580 graphics cards in a computer at his parents’ house. The network, later known as AlexNet, was too large to fit in the 3 GB of memory on a single card, so he split it between the two. Training took about a week. AlexNet won the ImageNet competition by a wide margin, and it’s widely seen as the moment modern deep learning took off and GPUs became AI hardware.

Fourteen years later, the same kind of hardware runs vision inspection, robotics, and other physical AI workloads on factory floors, in stores, and on machines. Instead of one GPU in a bedroom, it’s hundreds of GPUs spread across sites that nobody can walk over to and check.

Alex knew exactly how much memory his GPUs were using, because he was sitting next to them. With GPU metrics in the host metrics topic, you can now know the same about every GPU in your fleet, without sitting next to any of them.