January & February 2026: Feature releases & highlights
More structured navigation menu. Enhanced deployment editor. Built-in webhook. Terraform integrations.
- More structured navigation menu: the main navigation has been updated to better support a growing set of features
- Enhanced deployment editor: The deployment UI has been enhanced with guided label expression editing, and a simpler site-selection option for labs and early experiments, making it easier and less error-prone to target deployments.
- Built-in webhook support: you can now forward topics such as system alerts directly over webhooks with minimal configuration.
- Terraform provider: manage Avassa resources as code with Terraform, aligning edge operations with established Enterprise IT automation practices.
More Structured Navigation with Custom Pinned Menu
As the Avassa Edge platform continues to evolve, the main navigation has been updated to better support a growing set of features. The menu is now organized into logical groups, making it easier to discover and navigate functionality.
At the top of the menu, a Pinned section provides quick access to commonly used areas, defaulting to key views such as Applications and Sites. Users can also personalize this section by pinning their own frequently used items. In the example below, the web-based supctl has been added to the pinned section.
Items in the pinned section can be reordered using drag and drop, allowing each user to tailor the navigation to their workflow.
Enhanced Deployment Editor
Deployments are at the heart of the Avassa Edge Platform. Label match expressions provide a flexible and fine-grained way to define exactly which edge sites should run a given application. This model scales well across large fleets and dynamic environments.
For early experiments, labs, or smaller fleets, however, working with labels can sometimes feel unnecessary. To address this, we have introduced a simpler targeting option where you can explicitly list site names instead of defining a label expression. You can now choose between:
- Explicit list of sites
- Label expressions
- All sites
The screen shot below shows the start of a new deployment with the different options
We have also significantly improved the label expression experience.
Instead of manually typing expressions and checking site labels in the site view, you can now use the new Expression editor. It provides:
- A list of existing site labels
- System-assigned labels
- Available operators (including the recently introduced regular expression operator
~) - Live preview of matching sites
Click “Expression editor”:
Which will help you define the label expression:
To the left you will see all labels available at your sites, system labels to the right. Available operators are shown above, note the recently introduced regular expression operator ~. As you build the expression you will see the resulting sites in the bottom.
Deployments automatically exclude uninitialized sites (sites where the hosts have not yet called home). This behavior is now clearly indicated both in the expression editor and in the general deployment view, in the examples below the iot-site is not initialized:
The same mechanism elaborated above are also available to specify the canary sites.
As mentioned above, you can now explicitly specify the target sites using site names. For small fleets and labs, this can provide a more straightforward way:
Together, these enhancements make deployments both more powerful for large-scale operations and more approachable for smaller environments.
Native webhook support
The Avassa Edge Platform includes a built-in pub/sub bus, Volga, that provides real-time access to key operational data, including alerts, audit logs, and container logs. These topics can be consumed via the UI, CLI, or programmatically through APIs, including WebSockets.
Many external event management and observability systems support webhooks as a fast and simple integration mechanism.
🆕 What’s New
Webhooks are now built directly into Edge Enforcer and Control Tower. You can stream alerts, audit logs, and other Volga topics directly to external systems.
Key benefits:
- Native webhook forwarding
- Supported by both Control Tower and individual sites
- Simplified integration with Slack, SIEMs, and event management platforms
Below is a minimal configuration example forwarding system:alerts to a Slack application.
(Note: The Slack URL is inlined for illustration purposes. In production environments, it should be managed securely as a secret.)
supctl create volga webhooks <<EOF
name: slack-alerts
site-placement:
sites:
- control-tower
topic: system:alerts
url: 'https://hooks.slack.com/services/...'
data: '{"text": "\${MSG_PAYLOAD}"}'
data-format: json
EOF
Dot notation can be used to access JSON fields in the Volga payload and format the data output.
And appearing in Slack:
You can also configure the edge sites to forward certain topics. A useful example is to forward application logs. A snippet for such a configuration is shown below:
supctl create volga webhooks <<EOF
name: my-app-logs
site-placement:
application-deployments:
- my-dep
topic-patterns:
- ^system:container-logs:my-app\..*
Note that the site placement now tells the webhook configuration to follow a specific application deployment, my-dep. This means that the webhook invocation will occur on all sites in the deployment. Also note the regular expression used to select the container logs (needed when there are multiple services and/or containers).
Read more: https://docs.avassa.io/how-to/volga-webhooks
Terraform provider
Amongst our customers, we see two main automation paths. Applications and deployments are automated through CI/CD pipeline integration, and site-related resources are automated with Infrastructure as Code tooling. For the latter, customers use our command-line tool, REST API, and, in many cases, the bulk API. We have taken a further step to help customers automate infrastructure setup.
🆕 Say hello to our Terraform provider, it is available on GitHub
We have mapped the following Avassa resources to Terraform resources:
- System settings
- Sites
- Site profiles
- Assigned sites
- Tenants
- Users
The overall process of using the Terraform provider:
- Write: In this first step in the Terraform workflow, you’ll declare your Avassa resources as code using the Hashicorp Configuration Language (HCL),
*.tffiles For example [main.tf](<http://main.tf>)from the documentation, first specify the Avassa provider, the define your resources, a minimal site is shown below:
terraform {
required_providers {
avassa = {
source = "avassa-systems/avassa"
version = ">= 0.0.2"
}
}
}
provider "avassa" {
# Must match a local supctl profile name
profile = "demo-edge.b2"
}
# 1) Create a minimal system site.
resource "avassa_system_site" "example" {
name = "example-site"
descriptive_name = "Example site"
type = "edge"
}
...
Initialize your working directory with the configuration:
$ terraform init
Initializing the backend...
Initializing provider plugins...
- Finding avassa-systems/avassa versions matching ">= 0.0.2"...
- Installing avassa-systems/avassa v0.0.2...
- Installed avassa-systems/avassa v0.0.2 (self-signed, key ID 233E15DEC87EA495)
...
Terraform has been successfully initialized!
Run the terraform plan command to an execution plan, which lets you preview the changes that Terraform plans to make to your Avassa environment.
$ terraform plan
Terraform will perform the following actions:
# avassa_system_site.example will be created
+ resource "avassa_system_site" "example" {
+ allow_local_unseal = (known after apply)
+ descriptive_name = "Example site"
+ ingress_allocation_method = (known after apply)
Left out configuration fields will get their default values, indicated by (known after apply).
Apply: Finally, you can accept planned changes to add or remove any infrastructure resources.
$ terraform apply
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
...
avassa_system_site.example: Creating...
avassa_userpass.example_user: Creating...
avassa_system_site.example: Creation complete after 1s [name=example-site]
avassa_userpass.example_user: Creation complete after 1s [name=example.user@example.com]
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
Read the Avassa Terraform documentation: https://docs.avassa.io/tutorials/terraform-provider
By adding a Terraform provider for Avassa, you can now manage edge-site configuration with the same declarative workflows they already use for cloud and infrastructure automation. This gives customers a consistent, repeatable way to define sites, making large fleets far easier to audit and scale.
ℹ️ This first release is for early users to provide feedback; resource definitions might change in upcoming releases.
Infrastructure as Code did not begin with Terraform. In the early 1990s, Mark Burgess introduced CFEngine and the idea of describing desired system state declaratively rather than scripting every operational step. That thinking evolved through tools like Puppet and Chef, and in 2014 HashiCorp released Terraform, establishing a cloud-agnostic model where infrastructure is defined as intent and reconciled automatically.
With the Avassa Terraform provider, edge orchestration joins that lineage. The Avassa Edge Platform already provides strong intent abstractions for the edge — defining what should run, where, and under what conditions — rather than how to configure each individual site. By exposing these abstractions through Terraform, edge deployments become part of the same declarative, versioned, policy-driven automation framework that Enterprise IT has been refining for decades.
The edge is no longer a special operational domain. It becomes another managed surface in the Infrastructure as Code model.