May 2025: Feature releases & highlights

Analyzing Resource Profiles, Dedicated Security Alerts, and Bulk Operations.

Analyzing resource profiles: Fine-grained resource control is essential in multi-tenant environments, but it can make it difficult for application owners to determine which limits apply to their deployments. To improve transparency, new actions have been introduced for inspecting and understanding the effective constraints imposed by resource profiles.
Separated security alerts: To enhance situational awareness and facilitate more effective alert routing, alerts are now categorized by type—health, application, and security. This allows for clear filtering, and a new dedicated security view in the Control Tower makes it easier to track incidents related to security posture.
Bulk load in supctl: We have enhanced supctl and backend support for loading a bulk of resources, such as applications, secrets, and deployments, in a single operation.

Analyzing resource profiles

Introduction to resource management

The Avassa Edge Platform features a granular and flexible resource management model that governs how applications request and consume system resources. Examples of supported resource types include:

CPU
Memory
Network bandwidth and access
Container volumes
Specialized devices (e.g., cameras, sensors, GPUs)

Site providers can define resource profiles that control access to these resources. Resource profiles can be applied at multiple levels:

Globally: defined at the platform level and applicable across all tenants; these can be scoped per site or individual host.
Per tenant: allowing differentiated resource limits per tenant, with optional site-level granularity.

These profiles are composable, meaning multiple profiles may coexist at a single site, with enforcement determined by both tenant context and site configuration.

This architecture ensures controlled and predictable resource usage, avoids noisy-neighbor issues, and supports secure, multi-tenant application deployments across large-scale, distributed edge infrastructures.

Diagram showing application resource requests being limited by resource profiles.

While this flexible model gives site providers fine-grained control over resource usage, it can sometimes be non-trivial for application owners to determine which resource constraints apply to their applications at runtime, especially in environments with overlapping global and tenant-specific policies.

To address this, the platform now 🆕 includes observability features that enable application owners to inspect the effective resource allocation for their applications, providing transparency into applied limits and facilitating troubleshooting and planning.

Observe application resource allocation

The first step in inspecting the resources allocated to an application service is to examine a running instance of the application. This can be done in the Web UI by clicking the </> View state yaml button, which gives you the complete YAML state

Screenshot of the Avassa UI showing the 'View state yaml' option for a service instance.

or supctl

supctl show --site electric-cinema applications popcorn service-instances pop-service-1

name: pop-service-1
application-version: "5.1"
oper-status: running
...
gateway-network:
  ...
  outbound-network-access:
    inherited: << Effect of resource profiles
      default-action: deny
      rules:
        192.168.100.101/32: allow
    from-application:
      allow-all: true
    combined:
      default-action: deny
      rules:
        192.168.100.101/32: allow
ingress:
  ips:
    - 192.168.72.102
  inbound-network-access:
    inherited: << Effect of resource profiles
      allow-all: true
    from-application:
      allow-all: true
    combined:
      allow-all: true
containers:
  - name: my-container
    id: e370c0a7c563
    oper-status: running
    ... << Actual resources
    memory: 1 GiB
    cpus: 1.0
    cpu-shares: 1024
    container-layer-size: 20 GiB
    devices:
      - /dev/rtc0
    gpus:
      - id: GPU-ee1b2a5c-3cd0-0c4a-a240-d87c22748a35

This output provides visibility into both explicitly allocated resources and any inherited restrictions imposed by system- or tenant-level resource profiles.

Given the multi-tenant nature of the Avassa platform and the layered composition of resource profiles, understanding why a specific restriction is in effect can sometimes be complex. To assist in troubleshooting, you can use the following diagnostic actions, depending on the resource in question:

inspect-allocated-resources provides detailed container-level insights into allocated CPU, memory, container layer sizes, device access, and GPU usage.
gateway-network/outbound-network-access/debug and ingress/inbound-network-access/debug help trace and explain applied network access policies at the service instance level.

🔎 Note: These debug actions are tenant-scoped. The results reflect the current tenant context and may differ when run as another tenant.

Running from supctl:

supctl do --site electric-cinema applications popcorn service-instances pop-service-1 \
    containers my-container inspect-allocated-resources

Or from the UI:

Screenshot of the Avassa UI showing the 'Allocated resources' option under the Containers tab.

This produces a number of sections:

effective-constraints: indicates the total sum of all constraints set by different resource profiles on different levels. A site provider will see the actual resource profiles, whereas an application owner will be informed that the constraints are inherited.
requested-resources: indicates the amount of resources requested in the application specification for the currently running version
default-resources: indicates the amount of resources corresponding to the default value from a resource profile. These are resources not explicitely requested. See more in <<tutorial>>
currently-allocated: indicates the amount of resources currently allocated to the running container, based on the combination of the requested amount of resources, default amount and effective constraints. Note that the value may not correspond to the effective-constraints, requested-resources or default-resources in case some of the resource-profile definitions were changed since the service-instance was started.
would-allocate: indicates the amount of resources that would be allocated to the container according to the current resource-profile definitions when restarted.

If this command is run as the application owner, the restrictions will be shown as inherited. If the command is run as the site provider, the actual resource profiles are shown. So communication between the site provider and application owner tenants is assumed, and these new inspection tools enables that.

Below follows examples:

Running inspect-allocated-resources as an application owner:

effective-constraints:
  memory:
    source: inherited
    constraint: 2 GiB
  cpus:
    source: inherited
    constraint: 4.0
  ...
requested-resources:
  devices:
    device-labels:
      - rtc
  gpu:
    labels:
      - nvidia
    number-gpus: 1
default-resources:
  memory:
    source: inherited
    default: 1 GiB
  cpus:
    source: inherited
    default: 2.0
currently-allocated:
  memory: 1 GiB
  cpus: 1.0
  cpu-shares: 1024
  container-layer-size: 20 GiB
  devices:
    - /dev/rtc0
  gpus:
    - id: GPU-ee1b2a5c-3cd0-0c4a-a240-d87c22748a35
would-allocate:
  memory: 1 GiB
  cpus: 2.0
  cpu-shares: 1024
  container-layer-size: 20 GiB
  devices:
    - /dev/rtc0
  gpus:
    - id: GPU-ee1b2a5c-3cd0-0c4a-a240-d87c22748a35

The output of running the command inspect-allocated-resources as a site provider is shown below. You now get the details of resource profiles in effect for the application tenant.

effective-constraints:
  memory:
    source: assigned-site-profile << Kind of profile
    profile-owner: provider
    profile-name: t-my-site << Which profile
    constraint: 2 GiB
  cpus:
    source: tenant-profile
    profile-owner: provider
    profile-name: t-acme
    constraint: 4.0
...
requested-resources:
  devices:
    device-labels:
      - rtc
...
default-resources:
  memory:
    source: assigned-site-profile
    profile-owner: provider
    profile-name: t-my-site
    default: 1 GiB
...
currently-allocated:
  memory: 1 GiB
  cpus: 1.0
  cpu-shares: 1024
  container-layer-size: 20 GiB
  devices:
    - /dev/rtc0
  gpus:
    - id: GPU-ee1b2a5c-3cd0-0c4a-a240-d87c22748a35
would-allocate: << After service restart
  memory: 1 GiB
  cpus: 2.0
  cpu-shares: 1024
  container-layer-size: 20 GiB
  devices:
    - /dev/rtc0
  gpus:
    - id: GPU-ee1b2a5c-3cd0-0c4a-a240-d87c22748a35

The supctl command to get to a tenant’s application is shown below:

supctl do --site my-site electric-cinema tenants acme applications popcorn \ 
inspect-allocated-resources

Or you can navigate to the site and tenant application in the UI:

Screenshot of the Avassa UI showing the 'Inspect allocated resources' option for an application.

Observe network access policies

The above sections described how to debug resource allocation; now let’s move to network restrictions.

By default, an application is not allowed to emit any outgoing traffic at the edge, and incoming/ingress traffic is also blocked. Applications can however request both as shown below:

...
services:
  - name: my-service
    network:
      ingress-ip-per-instance:
        protocols:
          - name: tcp
            port-ranges: "9000"
        inbound-access:
          allow-all: true
      outbound-access:
        allow-all: true

A site provider can restrict outbound and inbound traffic in resource profiles. In order to inspect any such limitations imposed by the site provider to the application tenant you can use the following commands. So that you know, these commands are only applicable for a parent tenant. To get network information for your own application you can get the service state as shown above.

If you are the site provider you can inspect restrictions for a certain tenant application using the subctl commands below:

supctl do --site electric-cinema tenants acme applications popcorn service-instances \
    pop-service-1 ingress inbound-network-access debug

supctl do --site electric-cinema tenants acme applications popcorn service-instances \
    pop-service-1 gateway-network outbound-network-access debug

Or in the Control Tower UI:

Screenshot of the Avassa UI showing the 'Debug outbound access' and 'Debug inbound access' options for an application. — Screenshot

An example output of debugging outbound-network-access could look like:

inherited:
  default-action: allow
  rules:
    192.168.100.106/32: deny
assigned:
  tenant: acme
  source: tenant-profile
  profile-name: allow-101-and-106-only
  default-action: deny
  rules:
    192.168.100.101/32: allow
    192.168.100.106/32: allow
from-application:
  allow-all: true
combined:
  default-action: deny
  rules:
    192.168.100.101/32: allow

A brief explanation follows:

inherited: indicates the network access access rules applied to the tenant running the action, in this case to the provider.
assigned: indicates that the site provider tenant has assigned a set of network access rules to application owner tenant acme.
assigned: indicates that the site provider tenant has assigned a set of network access rules to application owner tenant acme.
from-application: indicates the network access requested in the application specification
combined: is the network access rules applied to the running service instance, incorporating all of the above mentioned access rules.

Summarizing resource usage debugging

Below follows a summary of the above detailed feature descriptions

Inspect allocated resources: To view the actual resource limits applied to a service instance and its containers, check the service instance state.
As an application owner: Use the inspect-allocated-resources action on your container to view current limits. Note that this does not explain why the limits were applied. For full context, consult your site provider.
As a site provider: To understand resource profiles affecting an application owner, run inspect-allocated-resources on the tenant’s container. This reveals the impact of assigned resource profiles.
Debugging network restrictions: Use outbound-network-access/debug and inbound-network-access/debug actions to investigate applied network restrictions.

Security Alerts

The Avassa edge platform provides alerts that give early warnings for the health of the hosts, the deployed applications and any security related incidents. In order to separate and filter these three categories for different purposes, all alerts now has a 🆕 kind field with the following values:

infrastructureAlerts related to hosts, sites, cluster, etc.
applicationApplication related alerts.
securitySecurity related alerts.

It is strongly recommended that you forward these alerts to your dedicated operational tools, either by a Volga client or Webhooks.

In order to be able to focus on security in the Control Tower UI we have now added a dedicated security alerts view:

Screenshot of the Avassa Control Tower UI, displaying the new dedicated security alerts view. — Screenshot

Bulk load

In some cases—such as when working with applications—multiple related objects need to be managed together. This typically includes the application specification and associated secrets. The bulk operation feature enables users or systems to create and update these resources in a single batch. The bulk API is transactional: either all operations succeed, or none are applied. If any part of the transaction fails, all changes are rolled back to ensure consistency.

You can prepare a file with all objects and related operations in one file and then apply it through supctl:

supctl patch < mosquitto.yaml

The input file is a list of x-path links, operation and data like illustrated below:

---
x-path: /v1/config/strongbox/tls/ca/mosquitto
x-operation: replace
name: mosquitto
ttl: 3y
...
---
x-path: /v1/config/strongbox/vaults/mosquitto/secrets/cert
x-operation: replace
name: cert
...
---
x-path: /v1/config/strongbox/vaults/mosquitto/secrets/credentials
x-operation: replace
name: credentials
data: 
...
---
x-path: /v1/config/applications/mosquitto
x-operation: replace
name: mosquitto
version: "1.0"
services:
...

A convenient way of learning the paths and data to be applied is to use prepare the objects and then use subctl to show the full path and operation:

supctl show applications mosquitto --with-operation replace

x-path: /v1/config/applications/mosquitto
x-operation: replace
name: mosquitto
version: "1.0"
...

Security and Edge Computing

Edge environments are increasingly targeted in security incidents across industries. Below are a few real-world examples that underscore the importance of clear, actionable visibility into security-specific alerts:

Retail – Target Data Breach (2013): Attackers gained access via a third-party HVAC vendor and moved laterally through poorly segmented networks to reach point-of-sale systems. Demonstrates the risk of edge-connected systems with shared infrastructure.
Industrial – Norsk Hydro Ransomware Attack (2019): A LockerGoga ransomware infection disrupted operations across factories and smelters worldwide. Highlights the vulnerability of industrial edge systems with limited segmentation and weak update practices.
Telecom – T-Mobile Edge Device Misconfigurations (2021): Security researchers discovered exposed 5G edge routers and management interfaces due to misconfigured access controls. Underscores the risk of edge compute nodes with public interfaces lacking zero-trust protections.

For a deeper overview of how Avassa approaches edge security—including authentication, secrets management, and secure orchestration—see our Security Overview data sheet.

Highlighted resources

What is Edge AI? Key Benefits & Why You Should Use It

Smooth Sailing at the Edge: How to Migrate Legacy VMs to Containers with Avassa

Edge Observability – Shifting Left for Proactive Monitoring