Radius Community Update: August 2026

By Radius Maintainers |

Welcome to the August 2026 Radius community update! Radius is an open-source cloud-native application platform that helps developers define, deploy, and manage applications across any cloud or on-premises environment. It acts as an abstraction layer between your application and your infrastructure, letting you focus on building your app while platform teams keep control over how resources are provisioned.

August was a big month. Radius v0.60.0 shipped the first preview of the fully extensible Radius.* Resource Types, along with support for using standard Bicep and Terraform modules directly as Recipes. Radius Canvas, a way to model, review, and deploy an Application from inside the GitHub Copilot app, was also announced. Read on for what landed, what is coming next, and how to get involved.

Releases

Radius v0.60.0 (August 19)

Preview release of fully extensible Resource Types

Radius v0.60 introduces preview versions of a new set of Resource Types under the Radius.* namespace. Radius.* Resource Types are completely recipe driven and fully customizable. These new Resource Types are available by using the –preview flag on common Radius CLI commands such as `rad init. For more details, visit the newly rewritten documentation at https://edge.docs.radapp.io/.

Direct IaC module support

Until now, a Bicep or Terraform module used as a Recipe had to be wrapped to accept a context input and return a structured result output, which meant you could not point Radius straight at an Azure Verified Module or a Terraform Registry module. You can now reference a standard module as a Recipe: Radius resolves {{context.*}} parameters, runs the module through the existing driver, and maps its outputs back onto Resource Type properties. Existing wrapped Recipes keep working unchanged. See referencing an existing module for details.

Modernized internal hashing (SHA-1 to SHA-256)

Radius now uses SHA-256 instead of SHA-1 to generate internal resource identifiers, Terraform Recipe state keys, ETags, and change-detection tokens. These hashes are used only for uniqueness and change detection, never for security. The upgrade is transparent and requires no action: existing Applications, Environments, resources, and Terraform state are recognized through a built-in compatibility layer, so nothing is redeployed and no pods are restarted. A future release will complete the transition and remove the compatibility layer.

There are no breaking changes in this release. For full details, see the v0.60.0 release notes.

Radius v0.60.1 (August 26)

This patch release backports fixes for rad resource list --preview, live deployment graph support, custom Recipe pack reconciliation on repeat deploys, architecture-aware Container image builds, Azure OIDC token refresh and RBAC-propagation verification, and control-plane readiness during install and upgrade. It also reverts default Resource Group and Environment creation from rad install kubernetes. See the v0.60.1 release notes for the full changelog.

You can upgrade by updating your rad CLI and running rad upgrade kubernetes. Only incremental version upgrades are supported, so consult the upgrade documentation before you start.

Recipes and samples

The resource-types-contrib catalog grew alongside the release. Azure Container Instances Recipes were added, Radius.Messaging/rabbitMQ now provisions a real broker on Azure, and the Azure database Recipes report the details applications actually need, including a port property for MySQL, PostgreSQL, and SQL Server, and a Redis access key exposed separately from the connection URL.

The demo sample moved to the Radius.* Resource Types and gained two variants that connect the demo Container to a managed cache and a managed database, so you can see connections in action against Radius.Data/redisCaches and Radius.Data/postgreSqlDatabases.

Radius Canvas

Radius Canvas was announced this month in Introducing Radius Canvas on the Azure Developer Community Blog, along with a walkthrough video if you would like to see a demo.

As AI accelerates software development, understanding how an application fits together is becoming as important as generating the code itself. Radius Canvas brings that application-level context into the GitHub Copilot app. It gives you and your agents a shared application model that you can use to:

  • Understand the application across its workloads, dependencies, connections, and infrastructure
  • Preview how it will run in a target environment before you deploy
  • Deploy the application and its infrastructure through GitHub Actions
  • Visualize the impact of a code change across services and dependencies as part of code review

The same application model carries that context from development through review, planning, and deployment, so you and your agents do not have to reconstruct it from scattered files and configuration at each stage.

Radius Canvas ships in the radius plugin for the GitHub Copilot app and is organized into three areas. Applications renders your Application as a live graph with four views: modeled, as you designed it; planned, as you want it deployed; deployed, as it runs in your Environments; and diff, showing what changed between two branches such as a pull request against main. Environments is where you create and verify the landing zone your Application deploys to. Deployments provisions the infrastructure your Application needs and runs the deployment through a generated GitHub Actions workflow.

Radius Canvas is in preview. Try it from the how-to guide and tell us what you think by opening an issue.

Upcoming features

The following work merged to main in August after the v0.60 release and is not part of it. It offers a preview of what is coming next.

  • Deploy a template straight from a URL. rad deploy accepts an http(s) URL in addition to a local path, so you can deploy a Bicep or ARM JSON template without downloading it first.
  • Managed Secrets projected through connections. A single connection to a Recipe-backed producer can now carry both ordinary values and references to a managed Radius.Security/secrets resource, so consuming Recipes read secrets without values ever being copied onto the producer.
  • rad env delete --preview cascades. Deleting a Radius.Core Environment now removes the Applications and resources deployed into it instead of orphaning them, and the confirmation prompt states what will be deleted.
  • Deprecation warning for Applications.* types. rad deploy warns when a bicep template uses a legacy Applications.* type and recommends replacing it with the Radius.* types.
  • Recipe packs from another Resource Group. rad env create --preview and rad env update --preview accept --recipe-pack-group, so a Recipe pack no longer has to live in the Environment’s own Resource Group.
  • Unique Kubernetes namespaces for Environments. Radius.Core/environments now enforce namespace uniqueness, so two Environments can no longer quietly deploy into the same namespace.
  • More Resource Types and Recipes in the default Kubernetes Recipe pack. RabbitMQ and PostgreSQL was added to the default Kubernetes Recipe pack.

Community

Welcome to our new contributors. Two people merged their first contribution to the Radius repository this month:

  • @ryanwaite improved how the Azure verify workflow reports GitHub OIDC failures, then fixed verification during Azure RBAC propagation
  • @pujitha24 added the --recipe-pack-group flag described above and fixed rad deploy resolving a Radius.Core Environment ID in the wrong Resource Group

A Recipe is self-contained Bicep or Terraform, which makes resource-types-contrib one of the easiest places to start contributing. If you want to add support for infrastructure you use, browse the good first issues.

Get involved

Whether you are a developer looking to simplify cloud deployments or a platform engineer building golden paths for your team, we would love to have you join the Radius community: