September 2025: Feature releases & highlights

Dynamic devices, Cert management with ACME, UI state enhancements.

• We now support dynamic, plug-and-play devices. In addition to static devices bound to the host lifecycle, applications can automatically discover and use devices as they are connected or removed — enabling true runtime flexibility at the edge.
• We now support the ACME protocol for certificate management. In addition to Avassa’s built-in automation, you can plug into any ACME-compatible CA for seamless issuance and renewal — improving security, interoperability, and ease of use across your edge deployments.
• The Control Tower UI now provides more fine-grained real-time status indicators and clearer icons, including improved visualization of disconnected sites.

Dynamic Devices

Until now, device management in the Avassa Edge Platform has been based on static devices. Devices were discovered and tied to the host’s lifecycle. Once configured, they were known by the system and available to applications running on that host. This model works well for predictable, fixed hardware setups — such as GPUs, cameras, or sensors that are permanently attached to a node.

With this release, we introduce dynamic devices — enabling true plug-and-play scenarios at the edge. Applications can now react to devices appearing and disappearing without requiring host-level reconfiguration or application restarts. A USB camera plugged in at runtime, a removable storage device, or other hot-swappable hardware can now be made available directly to applications as soon as it becomes accessible.

This makes it significantly easier to support use cases with changing hardware environments — for example, retail environments with handheld barcode scanners, industrial sites with replaceable sensors, or transportation systems with devices that are only intermittently connected. The platform automates the discovery and lifecycle management of these devices, enabling application developers to focus on functionality rather than infrastructure complexity.

Devices in Linux are essentially files, known as “device files”. Each of these files is associated with a MAJOR and MINOR number, which are used to associate the device with a driver.

Doing a ls -l /dev/* will show something along the lines of:

$ ls -l /dev/rtc0
crw-rw---- 1 root root 250, 0 Sep 12 13:51 /dev/rtc0

This shows that this is a character device (the first c) and MAJOR, MINOR is (250,0)

To give a container access to that device, you would write an application specification like:

services:
  - name: ...
    containers:
      - name: ...
        devices:
          dynamic:
            rules:
              - type: character
                major: 250
                minor: any
                permissions: read,write,mknod

📖 Learn more in the Dynamic Devices tutorial.

Automated Certificate Management using ACME

Avassa already provides automated certificate issuance, renewal, and management through its built-in Strongbox / SSL CA capabilities. With the new ACME support, users now have a standardized protocol for requesting and renewing certificates from external or internal ACME-compatible CAs — reducing manual steps, increasing compatibility, and improving security for edge deployments.

Existing Certificate Automation in Avassa

• Avassa includes an SSL/TLS CA (Strongbox) service for issuing and managing certificates internally. This supports automatic generation when applications start, automatic key rotation, and renewal of root certificates.
• There are various types of “call home” certificates available (host-specific, site-specific, system-specific), with configurable TTLs and built-in renewal behavior for ensuring connectivity and security.
• Avassa already supports “auto-cert” features in its Vault / Strongbox APIs: certificates can be created on demand and renewed when needed for applications or hosts.

What ACME Adds: Problems Solved

Until now, integrating with an external CA required a manual import workflow, leaving you responsible for renewals and distribution. The new ACME support removes that burden by automating the full lifecycle, from issuance to renewal, while still giving you the flexibility to choose your CA.

• Standardization & Interoperability → ACME is a widely adopted protocol (RFC 8555) for automating issuance, renewal, and revocation of certificates. By offering native ACME support, Avassa can work with any ACME-compliant CA (internal or external), integrating more easily with existing infrastructures.
• Reduced Operational Burden → Less custom scripting or manual certificate management; ACME clients (or Avassa acting as ACME client) can handle domain validation and certificate renewal automatically.
• Faster Response to Changes → As sites go online/offline, hostnames change, or CA configurations evolve, ACME automation helps ensure certificates stay valid without human intervention or error.
• Improved Security Posture → Short‐lived certificates, automatic renewals, less chance of expired certs causing outages or vulnerabilities. Also, it is easier to integrate with TLS best practices.
• Flexibility with CA Choice → Users can choose public ACME CAs or internal/private ones, allowing for trust boundaries, compliance, or offline/air-gapped operation.

Feature Overview

With ACME support, certificates in Avassa become even easier to manage. Instead of scripting custom flows or handling renewals manually, you can let the platform request and refresh certificates automatically from an ACME server. Whether you connect to a public service like Let’s Encrypt or an internal enterprise ACME CA, the process is the same: Avassa takes care of the entire lifecycle, from issuance to renewal.

Certificates requested through ACME can include the full certificate chain, making them ready for immediate use by your applications. They also benefit from the same secrets distribution and lifecycle handling as other credentials in Avassa, ensuring that applications always receive updated certificates without downtime.

You can use variable substitution in certificate names, making it straightforward to generate site-, host-, or service-specific certificates automatically. Combined with automatic renewal thresholds, this ensures your workloads never face the risk of expired certificates — even in large fleets spread across thousands of locations.

In short: define what you need, point to your ACME server, and let the Avassa platform do the rest.

Below follows snippets of configuration to set up Control Tower to fetch certificates from Let’s Encrypt and use the Avassa distributed secrets manager to distribute the certs to edge sites. Details and some steps are omitted for simplicity; please refer to the ACME certificates guide for more information.

First step, create an Avassa ACME service configuration:

supctl create strongbox acme-services <<EOF
name: letsencrypt-prod
contact-email: admin@yourcompany.com
directory-url: <https://acme-v02.api.letsencrypt.org/directory>
callback-domains:
- yourcompany.com
- app.yourcompany.com
EOF

Create a distributed secrets vault:

# Create distributed certificate vault
supctl create strongbox vaults <<EOF
name: certs
distribute:
	to: all
EOF

Now configure the ACME service to request certs and populate the distributed vault

# Configure static request for automatic certificate provisioning
supctl create strongbox acme-services letsencrypt-prod static-requests <<EOF
names: app.yourcompany.com,api.yourcompany.com
vault: certs
secret: web-services
EOF

The ACME service will now automatically:

1. Request certificates for the specified names
2. Store certificates in the certs vault under the specified secret name
3. Distribute to all edge sites immediately
4. Renew automatically before expiration

UI State Enhancements

We’ve enhanced the state visualization in the Control Tower UI to provide operators with a clearer, more detailed view of what’s happening in real-time. Applications and services now display improved status indications, complete with intuitive icons that make it easier to understand the current state at a glance.

Building on the disconnected site scenarios introduced in last month’s highlights, we’ve also added clearer visual cues for when a site or host is disconnected. This helps distinguish between temporary communication issues and actual service-level events, reducing ambiguity and enabling faster troubleshooting.

These improvements are part of our ongoing work to make the Control Tower UI not just a monitoring dashboard, but a truly actionable operations view for large edge fleets.

Site States

The screenshots below illustrate a range of relevant site status indicators. They also build on a feature first introduced in the June 2025 highlights: the ability to configure the desired behavior when a site becomes disconnected. For example, you can now decide whether a disconnection should trigger an alert or simply be treated as expected behavior.

Application States

Some application states are illustrated below.

In the first example, an ongoing upgrade has not been completed on all sites; for instance, some sites are being disconnected (waiting for distribution) or an application upgrade window (waiting for scheduling).

It’s also important to note that for disconnected sites, (last screenshot), the UI displays the last known state of the applications — for example, showing them as running successfully — until the site reconnects and reports its current status.

Deployment States

For deployments, the UI now provides a clearer indication when a deployment has failed. Failures can occur for several reasons — for example, if required secrets were not distributed to the target sites, or if an application expects a device that is not available at a given site.

The final example illustrates another case: a deployment that refers to an application version that has not yet been defined (or it has been deleted)

As a small curiosity: the name ACME has a history beyond the protocol. The word comes from the Greek akmē (ἀκμή), meaning the peak or the highest point. It was popularized in the early 20th century as a brand name for a wide range of products, from tools to grocery stores, chosen because it began with “A” and would appear first in directories. That same idea carried into pop culture with “ACME Inc.” as the go-to supplier of all things imaginable. The ACME protocol follows in this tradition, aiming to be the pinnacle of simplicity for certificate automation.