Highlighted resources

April 2026: Feature releases & highlights

Avatar photoStefan Wallin


Restructuring of resource and site profiles, along with other enhancements.

Restructuring of resource and site profiles

Avassa supports fine-grained resource control across the fleet, covering resources such as GPU, memory, and disk. These controls operate along two distinct dimensions.

  1. The first is tenant-level control: what resources a tenant is allowed to use. For example, whether a tenant can access GPUs at all.
  2. The second is system-level control: how resources are constrained at a site. For example, limiting total CPU usage regardless of which tenant is consuming it.

To reflect these two dimensions, resource profiles are now clearly structured and named based on their role in the system:

  • tenant-resource-profile defines resource access and limits per tenant
  • resource-profile defines system-wide constraints, typically applied at site level

The site-profile—used to define common characteristics across sites—has also been updated with clearer naming and enhanced structure.

Below follows an overview of the updated model.

Diagram showing the relationship between site profiles, sites, resource profiles, and default resource settings in the updated system model.

If we start with a site as the focal point. A site can reference a site profile, which defines when applications, Edge Enforcer, and OS will be upgraded. Site profiles will support additional common site attributes in upcoming releases.

The site can also reference a (system) resource-profile which defines limits for memory, CPU, etc., and patterns for GPU and device discovery. By defining, for example, the GPU discovery patterns in a resource profile, you can easily configure hundreds of sites to use the same pattern.

You can also define system-wide defaults for this in the settings/resource-defaults path.

Now, let’s look at tenant profiles. How can you limit tenants’ use of resources?

The updated model for tenants and tenant-resource-profiles is outlined below:

Diagram illustrating how tenant resource profiles define device, GPU, and hardware limits for specific tenants like application developers.

tenant-resource-profiles limits resource access and access to devices and GPUs. Let’s say you defined a pattern to search for Tegra GPUs on certain sites. But you do want to reserve that for a certain tenant. This is managed through the tenant-resource-profile.

Below follow screenshots (new/updated in Control Tower) that illustrate the usage of tenant-resource-profile and resource-profile .

If you navigate to site profiles, you will be able to define the three kinds of upgrade windows:

Control Tower UI showing the configuration of a site profile named nightly-upgrades with a specific application upgrade window.
Screenshot

When navigating to a site, you can assign the site profile, for example, to make sure that applications are only upgraded nightly:

Interface for assigning a site profile, such as nightly-upgrades, to a specific site named Robot 1.

If you again navigate to sites, there is a new item “System resource profiles”, where you will be able to define GPU and Device label rules and then associate that to sites. For example, to search for Tegra GPUs define a corresponding rule in a resource profile:

System Resource Profiles screen in Control Tower defining a GPU label rule for Tegra GPUs within a profile named jetson.

Associate the resource profile with site(s):

Associating a system resource profile named jetson with a specific site in the Control Tower Sites menu.

For all sites with that system resource profile, a GPU label “tegra” will be generated if found. Application owners can then request that their application use that GPU.

For an application owner tenant to use a specific GPU, the corresponding label must be configured in the tenant-resource-profile and associated with the tenant. For example:

Configuring a tenant resource profile to include a specific GPU label, such as tegra, for application owner access.

And associate that with the tenant:

Associating a tenant resource profile named app with a specific tenant named applifer in the Control Tower configuration.

Read more:

Taken together, this model gives a clear separation between site-level constraints and tenant-level permissions, while keeping configuration reusable across the fleet. Resource definitions can be applied consistently across many sites, and access can be controlled independently for each tenant, making it straightforward to manage shared infrastructure without sacrificing control or predictability.

Other enhancements

  • OCSP (Online Certificate Status Protocol) stapling is a mechanism for verifying a certificate’s revocation status with the Certificate Authority (CA). Read more: https://docs.avassa.io/how-to/emqx-crl-ocsp
  • Enhanced UDEV tooling, new action to test a pattern match-udev-patterns. Read more: https://docs.avassa.io/tutorials/device-discovery#testing-udev-patterns-interactively
  • Variables are useful for making your application specifications generic while still specific to sites and tenants. We have now added support for variables in match-ipv4-range-labels and match-interface-labels
  • When creating a new site, the default value of when-disconnected is now treat-as-error. This means that disconnected sites will generate an alert, and deployments will stay in state deploying if sites are disconnected.