Highlighted resources

November & December 2025: Feature releases & highlights

Avatar photoStefan Wallin


Flexible secrets access and application deployment versions, certificate logging, Web UI enhancements.


This November–December release brings a set of improvements shaped directly by feedback from real users running the Avassa Edge Platform in production. Many of the new capabilities address practical day-to-day needs around security, deployment flexibility, and ease of use. Below is a selection of the updates now available.

Certificate audit logging

One key feature our customers appreciate is automated management of distributed secrets and certificates. We have now introduced enhanced, detailed logging of all certificate issuance and renewal events. For each such event, you can see which site and application uses the certificate, the issuing CA, and more. See the example below:

{
 "kind": "certificate",
 "occurred-at": "2025-11-26T21:36:27.193Z",
 "site": "edge-site1",
 "issuing-ca": "keycloak",
 "user": "root",
 "from-auto-cert": {
  "vault": "keycloak",
  "secret": "server-cert"
 },
 "application": {
  "application": "keycloak",
  "service": "keycloak",
  "container": "keycloak"
 },
 "properties": {
  "certificate-type": "server",
  "alt-name": [
   "DNSName:keycloak-1.keycloak.internal",
 ...
   "IPAddress:192.168.100.43"
  ],
  "serial": "0d:d2:79:5e:70:69:65:fc:1d:fb:c3:69:5a:88:36:40:55:6a",
  "expires": "2026-02-24T21:36:27.000000Z"
 },
 "certificate": "-----BEGIN CERTIFICATE-----\
 ...
 -----END CERTIFICATE-----"
}

These audit log records have a kind tag certificate. “Classical” audit log records representing API access are now tagged with kind api.

With this extended logging, your cybersecurity processes can capture detailed certificate events and integrate with any SIEM.

Read more:

Flexible application access control for secrets

In previous releases, access to a Strongbox secret could be restricted based on container image hashes using the allow-image-access list. This required specifying the exact hash of every image that should have access. In practice, this has proven difficult to work with: even minor changes to an image, such as rebuilding it with updated base layers, produce a new hash, forcing administrators to update their vault configuration constantly.

As a result, most users set allow-image-access to '*' (meaning “allow all images”), which defeats the purpose of precise access control and weakens security. This is now being deprecated in favor of an enhanced secret access mechanism.

🆕 To address these problems, a new setting; allow-application-access, is now available. Instead of relying on image hashes, access is granted based on the deployed application and service structure.

Entries in this list can take one of the following forms:

  • <application> Allow all services and containers within the application.
  • <application>.<service> Allow all containers within a specific service.
  • <application>.<service>.<container> Allow a specific container.

The screenshot below illustrates where all services and containers within the application theater-room-manager will be allowed access.

Avassa Web UI showing the allow-application-access setting for a vault secret with theater-room-manager selected.

As with the old setting, you may use '*' to mean “all applications may access this secret, but this should be avoided unless necessary.

This new approach makes access control predictable and resilient to image rebuilds, without sacrificing security.

Flexible application version control for deployments

Following the same approach as above for secrets, we have now added a more flexible, fine-grained version control for deployments. In previous releases, a deployment could refer to either a specific version or any version (*). But you might want to say that any 2.3.* version should automatically be deployed. This is now supported, so the version field in the deployment is a wildcard pattern. (Note well that the Avassa platform as such does not impose or interpret the version string in any way.)

This means that you are not caught between two corners for making automatic rollouts.

The example below illustrates a deployment that will automatically deploy any “2.*” robot controller:

Deployment configuration in Avassa showing a wildcard 2.* used in the application version field for flexible rollouts.

Web UI enhancements

Web UI support for application upgrade windows

Last year, we introduced the application upgrade windows functionality. This means you can configure different upgrade windows across sites. Your central deployment team can roll out a new version without knowing the sites’ constraints. The Avassa Edge Platform will put upgrades in a local queue at the site.

We have now added form support in the Web UI to configure upgrade windows. In the main menu on the left, select Site Profile, then create a profile with application upgrade (”your” applications) and site maintenance windows (supd upgrades).

Avassa Web UI form for creating a site profile with a scheduled application upgrade window.

On the site object, you can now add site profiles:

Site details view in the Avassa Web UI showing the assignment of a site profile to a specific site.

This means you can configure multiple site profiles for a site. To easily see all scheduled “windows” you can inspect that in a new calendar tab:

Calendar tab in the Avassa Web UI displaying scheduled application upgrade windows for an edge site.

Read more:

https://docs.avassa.io/how-to/application-upgrade-windows

https://docs.avassa.io/fundamentals/applications-and-deployments#application-upgrade-windows

Application upgrade windows are the most relevant for most customers. Seldom do you need to schedule maintenance windows for Edge Enforcer (supd) upgrades. An Edge Enforcer upgrade has no impact on running applications. Local Edge Enforcer APIs, (if used), will be not responding for less than a minute. Read more:

https://docs.avassa.io/how-to/controlling-supd-upgrade

Enhanced YAML editor

As you probably know, all Avassa resources are available via the REST API as YAML or JSON objects. This is well represented in the Web UI, where you can always retrieve the YAML/JSON representation. (Note that there is a setting in your user preferences to choose JSON or YAML).

When the Avassa Edge Platform is deployed in production, most of our customers automate resource modifications in their pipelines. But when you learn the product and experiment, you typically work with a mix of the forms and the built-in YAML editor. This editor is now enhanced in several ways:

  • enhanced syntax highlighting
  • fold/unfold of the YAML contents
  • diff viewer, when editing, you can inspect the changes you have made before saving

For example, when editing the application upgrade above, if you modify the time, you can inspect the edit before submitting:

Avassa YAML editor diff viewer showing a side-by-side comparison of configuration changes.

Fold the YAML:

Avassa Web UI showing the enhanced YAML editor with folded content for easier configuration management.

This new YAML editor will be gradually rolled out across additional objects in upcoming releases.

DNS information

Applications that request ingress addresses will also be allocated DNS A records, one for each instance, and one A record shared for all service instances that will return the addresses of all service instances that are in the ready state. This shared address is useful when a client needs to access the service, and wants to reach an instance that is up and running.

Here is an example with the application Mosquitto running two replicas:

supctl show --site iot-site applications mosquitto-anon --fields=service-instances/"[name,application-network/dns-records,ingress/dns-records]"
service-instances:
  - name: mqtt-1
    application-network:
      dns-records:
        - mqtt-1.mosquitto-anon.internal. 15 IN A 172.30.0.1
        - mqtt.mosquitto-anon.internal. 15 IN A 172.30.0.1
    ingress:
      dns-records:
        - mqtt-1.mosquitto-anon.b2.iot-site.site.demo-edge.b2.avassa.net. 15 IN A 192.168.71.8
        - mqtt.mosquitto-anon.b2.iot-site.site.demo-edge.b2.avassa.net. 15 IN A 192.168.71.8
  - name: mqtt-2
    application-network:
      dns-records:
        - mqtt-2.mosquitto-anon.internal. 15 IN A 172.30.0.2
        - mqtt.mosquitto-anon.internal. 15 IN A 172.30.0.2
    ingress:
      dns-records:
        - mqtt-2.mosquitto-anon.b2.iot-site.site.demo-edge.b2.avassa.net. 15 IN A 192.168.71.7
        - mqtt.mosquitto-anon.b2.iot-site.site.demo-edge.b2.avassa.net. 15 IN A 192.168.71.7

The shared A record, mqtt.mosquitto-anon.b2.iot-site.site.demo-edge.b2.avassa.net. will resolve to the two IP addresses of the different instances. The Edge Enforcer’s name server will return these addresses with a short TTL and a round-robin scheme, ensuring that clients are distributed across the different instances. In turn, each instance also has its own A record, with the service instance number as a suffix, for example: mqtt-2.

For application communication on the same application network, there are A records in the special .internal domain. These records can be used to either reach specific instances of a service or, again, to reach a service by a single name that resolves to the IP addresses of all ready instances. The information on what records are available on a site is now visible:

DNS information view in the Avassa Web UI displaying A records and IP addresses for service instances.

Enable/Disable users

You can now enable/disable local users in Control Tower:

Control Tower interface showing the new feature to enable or disable local users with status indicators.

Other minor enhancements

  • Revocation list: CA certificates include a CRL Distribution Point extension that specifies where certificate revocation lists can be retrieved. While modern systems more commonly rely on short-lived certificates, CRLs are still supported and can be used by clients to verify revocation status. Avassa-generated CA certificates now publish CRLs on port 4664, making revocation information available when needed:
X509v3 CRL Distribution Points:
  Full Name:
   URI:<http://api.test:4664/crl/sys/api-root/1>
  Full Name:
   URI:<http://api.internal:4664/crl/sys/api-root/1>
  Full Name:
   URI:<https://api.internal:4646/crl/sys/api-root/1>
  • In the document structure, we have introduced a second layer of section headings to make navigation easier. For example, see the new structure in Fundamentals:
Avassa documentation menu showing the new second layer of section headings for improved navigation.

Regexp or wildcards?

In this month’s release highlights, we mention that wildcards are now supported as version expressions in deployments. In an earlier release highlights, we mentioned support for regular expressions when matching labels in deployments. Similar patterns appear in other parts of the Avassa platform. For example, upgrade rules that express which application versions are allowed to upgrade from use wildcards, since it is natural to say something like upgrade-from “2.1.*”. In Volga, on the other hand, the search topic content supports regular expressions, which are better suited to a programmatic API where full expressive power is expected.

Wildcards and regular expressions solve related but different problems. Wildcards are readable and straightforward, intended for humans to express common patterns such as “2.1.” or “prod-”, with the goal of clarity rather than expressive power. Regular expressions are more powerful and precise, well-suited for programmatic use cases such as filtering message content or complex label matching, for example, ^prod-(eu|us)-[0-9]+$. Historically, wildcards trace back to early file-system globbing in Unix shells. At the same time, regular expressions originate in formal language theory and text-processing tools, which explains why they feel natural in different parts of the platform.