Monthly Highlight Report

September 2026: Feature releases & highlights

Stefan Wallin 10 minute read October 8, 2026

Automatic redeploy, Site history, OTEL Exporter

The september releases focus on automation and visibility — deployments that adapt to your fleet on their own, a unified history of site events, and OpenTelemetry export for your existing observability stack

Automatic redeploy: Deployments placed by label expression can now automatically pick up new matching sites and drop sites that no longer match, with no manual step required. Choose how far that automation goes, from fully manual to fully hands-off.
Site history: A per-site timeline that merges Control Tower and site-level events into one chronological view, so you can see exactly what happened — and why — in any time window without building an external pipeline.
OTEL Exporter: Export Volga logs and metrics directly to any OpenTelemetry-compatible backend, sibling to the existing Webhooks exporter, with the same flexible site targeting including following a deployment wherever it runs.

Automatic redeploy

Deployments placed with a label expression track the sites matching that expression — but until now, adopting changes to that match set was a manual step. If you added a new site with a matching label, or changed labels on existing sites, the deployment wouldn’t pick that up on its own: you had to explicitly call the redeploy action to re-evaluate the label expression and trigger deployment to (or removal from) the affected sites. (The name is a bit misleading — it doesn’t redeploy the application, it just re-evaluates placement.) The manual step was deliberate: without it, adding or renaming a label could silently undeploy an application somewhere you didn’t intend.

For large-scale automated rollouts, though, waiting on a manual step doesn’t fit — you want new sites to pick up the deployment as soon as they match. The deployment now has a configurable auto-redeploy setting for exactly that:

never (default) — preserves today’s behavior; placement changes only take effect when you explicitly call redeploy.
only-add-sites — automatically deploys to newly matching sites, but leaves the application running on sites that no longer match; removal still requires calling redeploy.
always — automatically deploys to newly matching sites and undeploys from sites that no longer match, keeping the deployment fully in sync with the label expression at all times.

Set directly from the deployment form’s new Automatically redeploy dropdown, or in YAML alongside placement:

name: image-classifier
application: image-classifier
application-version: "2.0"
placement:
  match-site-labels: edge-ai
auto-redeploy: always

Site history: a unified timeline, per site

Forwarding Volga’s rich per-site logging through Webhooks or OTEL to a central logging solution is the right move when you want to analyze and correlate across topics and sites at scale. But often the question is much narrower: what actually happened on this site, in this window of time — without standing up an external pipeline just to find out.

That’s what the site’s new History tab answers. It merges the relevant logs into a single chronological timeline, filterable by event type — application and container lifecycle events, host and site alerts, deployment events, config changes, info logs, and more — with live counts per type and the option to keep listening for new events as they happen. A question like “what happened on this site on Monday between 8 and 9 AM” gets a direct answer, with every event in the order it occurred and the raw payload one click away.

The timeline isn’t limited to what the site itself knows about. Each event’s System topic and Noticed by columns show where it actually came from, and the two are deliberately interleaved: a deployment initiated at the Control Tower shows up as Application waiting to be scheduled and Application starting (noticed by control-tower, via deployment-events), immediately followed by the site’s own Container starting, Container ready, and Application running (noticed by the site, via all-scheduler-events) as that deployment plays out locally. A container starting is a scheduler event recorded at the site — but it’s the result of a deployment event that originated at the Control Tower, and History brings both into the same view so the cause and its effect sit side by side instead of requiring a separate lookup.

Alongside it, scheduler events now carry a reason field explaining why an application started or restarted — was it a fresh deployment, a config or secret change, a manual restart, a retry after a failed start, an upgrade, or a reschedule triggered by the host being drained, quarantined, down, or removed? For a rescheduled instance, a companion rescheduled-reason field pins down exactly which of those it was. What used to take some guesswork from timestamps and correlation is now a labeled fact sitting right on the event.

Together, the two features turn “why did my application restart” from a multi-log investigation into a single glance at the site’s History tab.

This site’s History tab shows a deployment and a failure side by side, latest item first. Starting from the bottom in the list we can see that the popcorn-controller deployment is received and queued at the Control Tower, scheduled to stockholm-sergel, pulls its image, starts and becomes ready, and completes — visible as a run of deployment-events from control-tower interleaved with the matching all-scheduler-events and log lines from the site itself. Minutes later, host h02 goes down and the site flips to “In distress” — surfaced immediately as site-alerts, also noticed by control-tower. One timeline, one place to see both what was deployed and what then broke.

The following topics are used:

Site topics: system:logs, system:scheduler-events, system:alerts, system:events, and system:site-alerts
Control tower topics: system:deployment-events and system:config events related to the site.

For the full list of what can trigger an application to start or restart, see the reason field reference in the appendix at the end of this release highlights — it’s also a useful primer on how Avassa manages application lifecycle in general.

OpenTelemetry, OTEL exporter

Every Avassa site continuously produces the data you need to run a fleet with confidence: proactive threshold alerts on disk, memory, and volume usage, application and host metrics sampled every 30 seconds, container logs from every workload, and a cryptographically signed audit trail of every authenticated operation. Not everything lives at the edge; deployment events and organization-wide audit logs live centrally at the Control Tower. That’s exactly the mix of signals proactive alerting, health monitoring, and post-mortem investigation each depend on.

This release adds a sibling to the Webhooks exporter we shipped earlier this year: instead of forwarding Volga topics as Webhook calls, the new OTEL exporters forward them as OpenTelemetry metrics and logs. Same underlying idea: stream Avassa’s operational data straight out of Volga to wherever your team already watches for problems, but OTEL is the interoperability layer nearly every modern monitoring, observability, and SIEM platform speaks natively, so it’s the natural next hop for teams standardized on an OTLP-based stack (Grafana, Datadog, Splunk, Elastic, and others) rather than webhook-based ingestion.

Two exporter types are available:

Metric exporters forward host and application metrics.
Log exporters forward any Volga topic — alerts, container logs, audit events and more — with built-in extraction of severity and other fields straight out of the message payload.

Both can be placed at the site level — where most metrics and application/container logs originate — or centrally at the Control Tower, to pick up fleet-wide topics like deployment events and organization-wide audit logs.

Streaming platform alerts into a SIEM or observability backend for proactive monitoring, for example, is just a few lines of config:

supctl create volga otel-log-exporters <<EOF
name: alerts-exporter
site-placement:
  all-sites: true
topics:
  - system:alerts
protocol: http-json
url: https://otlp-gateway-prod-eu-north-0.grafana.net:443/otlp/v1/logs
headers:
  - name: Authorization
    value: 'Basic \${token}'
severity-text: '\${severity}'
variables:
  - name: token
    value-from-vault-secret:
      vault: tokens
      secret: grafana
      key: token
  - name: severity
    value-from-message:
      json-pointer: /payload/severity
EOF

Credentials are pulled securely from Strongbox rather than hardcoded, and exporters automatically restart if their configuration changes or the collector becomes unavailable.

At a glance:

Flexible targeting: apply an exporter to all sites, an explicit list of sites, sites matching a label expression, or the sites a specific application is deployed to. That last option means export configuration can follow a deployment automatically: point an exporter at an application once, and it keeps exporting that application’s logs wherever it gets scheduled, with no per-site setup as the fleet changes.
Three OTLP transports: gRPC (default), OTLP/HTTP with JSON, or OTLP/HTTP with Protobuf, matching whatever your collector expects.
Message-level filtering: include or exclude log records by string or regular-expression match before they’re ever sent, to keep noisy topics from flooding your SIEM.
Configurable batching: tune batch size and delay to balance export latency against collector load.
Enterprise TLS : validating the TLS connection to the remote endpoint.
Rich templating: construct URLs, headers, severity and body fields from Volga message fields, vault secrets, and system variables (site name, tenant, site labels, DNS zones), so one exporter definition adapts per site without hardcoding.

Read the full Volga OpenTelemetry exporters guide for metric exporters, application-log streaming, and severity extraction with regular expressions.

Other enhancements

The Edge Enforcer installer now supports additional options to enable installation customization and offline installation process. The preflight script now also works through a proxy.

New options:

--state-dir DIR Store state under this path, default: /var/lib/supd/state
--volume-dir DIR Store application volumes under this path, default: /var/lib/supd/volumes
--offline Do not use the network during the installation step, nothing is fetched from a package repository.

Two Right Answers, One Standard

OpenTelemetry’s lineage runs through Google’s 2010 Dapper paper on distributed tracing, and through Ben Sigelman personally — he worked on Dapper, then left to co-found LightStep and create OpenTracing (2016), a vendor-neutral tracing API. Google, separately, open-sourced its own OpenCensus (2018), which did metrics and tracing with real SDKs included. For a year the industry had two competing “open” standards splitting the ecosystem — until 2019, when the two teams merged them into OpenTelemetry under the CNCF: OpenTracing’s clean API design plus OpenCensus’s implementation, later expanded with metrics and logs. It’s now one of CNCF’s largest projects after Kubernetes, graduating in May 2026 — a rare case of two independently-invented “right answers” being merged by the people who built them, which is a big part of why it stuck.

Details: services, and container start and restart reasons

Why did the container or service restart?

mounted-file-change: The service instance is restarted because a mounted file was changed.
secret-change: The service instance is restarted because a secret that is used in the environment or on the command line was changed.
config-change: The service instance is restarted because some configuration parameter that is used in the environment or on the command line was changed.
restart: The service instance is restarted due to an invocation of the restart action.
retry: The service instance is restarted because an earlier attempt to start it failed.
upgrading: The service instance is restarted as part of being upgraded.
rescheduled: The service instance is started on another host, because the host it ran on is no longer a candidate, or because it was moved by an invocation of the reschedule action. The service-instance-starting event tells which of these it was.
admin-up: The service instance is started because it was administratively brought up again, e.g., when the host it runs on is no longer drained.
host-restart: The service instance is started because supd was restarted, e.g., when the host was rebooted, and the instance’s containers were no longer running.
container-failed: The container is restarted because it exited with a non-zero status.
startup-probe-failed: The container is restarted because its startup probe failed.
liveness-probe-failed: The container is restarted because its liveness probe failed.
container-exited: The container is restarted because it exited with status 0. This is reported for containers that are allowed to exit, e.g., a VM that reboots.

They can also be rescheduled for different reasons:

host-drained: The host the service instance ran on was put into drain mode.
host-out-of-service: The host the service instance ran on was put into maintenance mode out-of-service.
host-quarantined: The host the service instance ran on was quarantined.
host-down: The host the service instance ran on is down.
host-removed: The host the service instance ran on is no longer a host in the site.
reschedule-operation: The service instance was moved in order to even out the distribution of service instances among the hosts in the site, due to an invocation of the reschedule operation.

Stefan Wallin