Radius Blog – 2025

Posts: Announcing Radius v0.54

Thu, 18 Dec 2025 00:00:00 +0000

Today, we’re excited to announce the release of Radius v0.54. This update brings several improvements and fixes detailed below. You can find the full release notes on our GitHub releases page.

If you’re new to Radius, it’s a cloud-native application platform designed to simplify the deployment and management of Applications. To get started, visit our getting started guide and learn how to install Radius and create your first app.

Fixed `rad workspace show` errors when no current workspace exists

The rad workspace show command has been updated to improve usability. Previously, if no workspace was set, the command would return an error, which could be confusing. With this release, the command now logs an informational message to guide you when no current workspace exists. This change ensures a more user-friendly experience when managing workspaces. For more details, refer to the CLI documentation.

Fixed `rad credential show azure` command

A fix has been made to the rad credential show azure command. Previously, this command would fail with a runtime error: invalid memory address when attempting to display Azure Service Principal credentials. This issue has been resolved, and the command now correctly displays the Azure credentials you’ve configured for Radius.

Upgrading to Radius v0.54

Upgrading to the latest version is straightforward. First, update your Radius CLI, then run the rad upgrade kubernetes command. Note that only incremental version upgrades are supported, so ensure you’re upgrading from the previous version. For detailed instructions, consult the upgrade documentation.

New contributors

We’re thrilled to welcome new contributors to the Radius community! A special thanks to @filipevrevez for their first contribution in PR #10749. Your contributions help make Radius better for everyone.

Learn More and Get Involved

We would love for you to join us to help build Radius:

Try the Radius Tutorial
Checkout the Radius roadmap and influence future features at https://aka.ms/radius-roadmap
Join our monthly community meeting to see demos and hear the latest updates (join the Radius Google Group to get email announcements)
Join the discussion or ask for help on the Radius Discord server
Subscribe to the Radius YouTube channel for more demos

Posts: Deploy a RAG chatbot app using Radius

Mon, 24 Nov 2025 08:00:00 -0800

Agentic AI applications are rapidly becoming a cornerstone of modern software, enabling systems to reason, act, and interact with data in unprecedented ways. As these intelligent applications grow in complexity, managing their infrastructure and governance becomes increasingly challenging. For instance, a Retrieval-Augmented Generation (RAG) chatbot application might require a combination of vector databases, large language models (LLMs), and traditional compute, on top of which considerations like dependency management, security, and compliance are layered. Indeed, when looking at some of the most popular AI sample applications, we see that they often involve multiple components and services that need to be orchestrated outside the bounds of the core application itself before the application can even run.

We wanted to illustrate how Radius can streamline the building and deploying of these modern AI workloads, ensuring they are portable, secure, and easy to manage. This brings us to the demo that we’ve built: leveraging Radius to model and deploy the azure-sql-db-chat-sk sample chatbot from the open source Azure Samples repo. This demo illustrates how Radius simplifies the deployment and governance enforcement of intelligent applications across multiple environments. Mark Russinovich presented this demo recently at the Microsoft Ignite conference:

To try the demo for yourself, follow the Radius deployment instructions in the repo.

Overview of the sample chatbot application

The application is a chatbot designed for insurance claims agents. It uses a SQL Server database to store and retrieve data, leveraging both Retrieval-Augmented Generation (RAG) and Natural-Language-to-SQL (NL2QL) mechanisms. This allows the bot to chat effectively using both structured (tables) and unstructured (vector embeddings) data.

The bot is built using the Semantic Kernel agent orchestration framework and takes advantage of the native vector support in SQL Server.

Modeling the chatbot app using Radius

First, we containerized the chatbot application code using Docker and pushed the container image to a container registry. Then, we used Radius to model the entire application, defining the relationships between the chatbot container and its dependent resources: the SQL Server database and OpenAI services.

Radius Resource Types and Recipes for dependencies

We defined Radius Resource Types to model the SQL Server database and AI models, which are deployed using Bicep Recipes. These Recipes encapsulate the provisioning logic for these resources to abstract them away from developers, allowing for dynamic infrastructure decisions at deploy time. For example, the SQL Server database Recipe provisions different Azure SQL Database SKUs based on the target Radius Environment. This abstraction allows developers to request these resources without needing to know the underlying infrastructure details. The developer simply requests a “SQL Server database” or an “AI model,” and Radius handles the provisioning based on the target Environment’s configuration.

Radius Application definition

As mentioned above, the developer is able to build a declarative application definition that focuses on the application logic and dependencies without worrying about the underlying infrastructure. For our demo chatbot app, the application definition includes a container for the chatbot service, a SQL Server database for the vector store, and AI models for chat and embeddings, all encapsulated in a single application definition. Radius builds the application graph dynamically based on the resources that get deployed and connections between resources are automatically established.

Multi-environment deployment

In our demo, we targeted three distinct Radius Environments:

ACI: A lightweight environment for quick testing running on Azure Container Instances
AKS Dev: A development environment running on Azure Kubernetes Service
AKS Prod: A production environment with stricter governance running on Azure Kubernetes Service

Radius deploys the exact same application definition to all three environments without requiring any changes to the code or the app.bicep file.

Governance and guardrails using Radius

A key highlight of the demo is leveraging Radius for seamless governance enforcement. We demonstrated how Radius Environments can enforce different policies and configurations for each deployed resource transparently to the application and developer.

Specifically, we implemented separate database configurations (SKUs, disaster recovery, multizone redundancy) for Dev and Prod environments and added AI content filtering to prevent “jailbreak” attempts in Prod.

Dev Environment: The SQL Database uses a lower SKU and does not have disaster recovery or multizone redundancy enabled for cost savings. The jailbreak content filtering is relaxed or disabled for testing purposes.
Prod Environment: The SQL Database uses a higher SKU with disaster recovery and multizone redundancy enabled for resilience. The jailbreak content filtering is strictly enforced.

This configuration is managed entirely through Radius Environment parameters. The SQL Server database and AI model Recipes accept parameters configured at the Environment level. When deploying to Prod, the Environment automatically passes the database resiliency and strict content filtering configurations to the Recipes.

Seeing it in action

The platform engineering team sets up the Radius Resource Types, Recipes, and Environments by running the below commands:

# Create the Resource Types from the types.yaml file
rad resource-type create --from-file ./types/types.yaml

# Deploy each Environment using its respective definition file 
# (i.e. aci-dev.bicep, aks-dev.bicep, aks-prod.bicep)
rad deploy ./environments/<env-definition>.bicep --parameters subscriptionId=<subscriptionId> --parameters resourceGroupName=<resourceGroupName>

Developers can then deploy the chatbot app to any of the available Environments using the same application definition file and providing the desired chat and embedding model names as parameters:

# Target the aci-dev environment using gpt-3.5-turbo and text-embedding-ada-002 models
rad deploy app.bicep --environment aci-dev --parameters chatModelName=gpt-35-turbo --parameters embeddingModelName=text-embedding-ada-002

# Target the aks-dev environment using gpt-4 and text-embedding-3-small models
rad deploy app.bicep --environment aks-dev --parameters chatModelName=gpt-4 --parameters embeddingModelName=text-embedding-3-small

# Target the aks-prod environment using gpt-4 and text-embedding-3-small models
rad deploy app.bicep --environment aks-prod --parameters chatModelName=gpt-4 --parameters embeddingModelName=text-embedding-3-small

When running the demo, the difference in behavior is observed based on the target environment:

Deploy to Dev: We deploy the app to the AKS Dev environment and see the database configured with a lower SKU and no disaster recovery or multizone redundancy. We attempt a jailbreak prompt, and the bot might respond (or the filter is loose).
Deploy to Prod: We deploy the same app to the AKS Prod environment and see the database configured with a higher SKU and disaster recovery and multizone redundancy enabled. We attempt the same jailbreak prompt. This time, the Azure OpenAI content filters kick in, and the chatbot refuses to answer, flagging the attempt.

This demonstrates how platform engineers can enforce security and compliance standards (like database SKUs, redundancy, and AI safety) across environments without burdening developers with the details.

In summary

This demo showcases the “Write Once, Run Anywhere” promise of Radius, not just for compute, but for the entire application topology including dependencies and configuration. By decoupling the application needs from the infrastructure capabilities, Radius enables developers to move fast while ensuring platform engineers can maintain control and governance.

Check out the source code to try it yourself!

Get Involved with Radius

Monthly Community Meetings: Join the Radius Google Group for announcements.
Discord: Connect with us and other contributors on the Radius Discord.
YouTube: Watch demos and tutorials on the Radius YouTube channel.

Posts: Announcing Radius v0.53.0

Wed, 12 Nov 2025 04:12:56 +0000

Radius v0.53.0 is here! This latest release brings exciting updates to improve your experience with Radius, whether you’re deploying cloud-native Applications or managing internal developer platforms. You can explore the full release notes at Radius v0.53.0 Release Notes. If you’re new to Radius, visit radapp.io to learn more about the platform and check out the getting started guide to install Radius and create your first app.

Contour ingress controller installation re-enabled

Radius v0.53.0 reintroduces support for installing the Contour ingress controller during rad install kubernetes or rad init. This enhancement is made possible by the availability of the Contour Helm Charts. With this update, you no longer need to manually install and configure a Contour ingress controller before deploying Gateway resources. This streamlines the setup process and ensures a smoother deployment experience for your Applications.

Improved environment deletion experience

The rad env delete command has been enhanced to make Environment cleanup safer and more transparent. This update introduces differentiated prompts for deleting empty versus populated Environments, helping you understand the scope of deletion before proceeding. Additionally, progress messages have been added to provide clearer feedback during deletion operations. For more details, refer to the CLI documentation.

Better Onboarding & Learning Experience

This release brings a major documentation update, including a refreshed Quick Start, brand-new Concept pages that elevate Radius core concepts, and a redesigned 5-part Tutorial. Together, these improvements create a clearer, more intuitive learning journey that helps new users quickly understand Radius and start building with confidence.

New contributors

Radius v0.53.0 welcomes new contributors to the project. Special thanks to:

@koksay for their first contribution in PR #10614
@DariuszPorowski for their first contribution in PR #10771

Your contributions help make Radius better for everyone!

Upgrading to Radius v0.53.0

To upgrade to Radius v0.53.0, update your Radius CLI and run rad upgrade kubernetes. Note that only incremental version upgrades are supported. For detailed instructions, consult the upgrade documentation.

Learn More and Get Involved

We would love for you to join us to help build Radius:

Try the Radius Tutorial
Checkout the Radius roadmap and influence future features at https://aka.ms/radius-roadmap
Join our monthly community meeting to see demos and hear the latest updates (join the Radius Google Group to get email announcements)
Join the discussion or ask for help on the Radius Discord server
Subscribe to the Radius YouTube channel for more demos

Posts: Happy 2nd birthday, Radius!

Tue, 21 Oct 2025 00:00:00 +0000

On October 18, 2025 we celebrated two years since Radius was released as an open-source project! This milestone gives us a chance to reflect on our collective journey and the significant progress made with the community. This past year has been transformative for Radius, with a focus on providing an extensibility model for enterprises adopting Radius into their internal developer platforms and adding capabilities that improved operational maturity of the platform.

The Radius community has grown with new and existing contributors providing thoughtful feedback and collaborative feature development. We’ve delivered consistent monthly releases with features that catered to both application developers and platform engineers, improved product documentation and community resources. The Radius maintainers extend their sincere gratitude to everyone who has participated in contributing code, writing documentation, testing features, and providing feedback. Your contributions have been essential to progressing the Radius vision, and we’re excited to continue this collaboration as we further evolve the platform.

Year in review: Radius feature highlights

Radius Resource Types are one of the most transformative enhancements to the platform this year because they make Radius fundamentally extensible. Instead of being limited to a fixed catalog of built-in resources, platform engineers can now define custom resource types tailored to their organization’s workflows, policies, and infrastructure. Resource Types act as a contract between application developers and their internal developer platform, abstracting away the complexity of underlying cloud resources while enabling seamless integration with existing Infrastructure-as-Code tools like Terraform and Bicep. This decoupling of resource definition from implementation empowers platform teams to enforce best practices and evolve infrastructure without disrupting developer workflows, while developers gain a simplified, application-centric experience. We are building a community driven library of Resource Types and Recipes in the Radius resource-types-contrib repository to accelerate development and share best practices for defining application-centric abstractions in Radius.
Native GitOps integration with Flux enables teams to define applications and infrastructure with Radius, and then use Flux to deploy and manage them with GitOps practices. The integration includes a new Flux Controller that watches for changes in Git repositories and a new Deployment Template Controller that creates, updates, or deletes applications based on these configurations. This brings the operational benefits of GitOps workflows while preserving Radius’s application-centric approach.
Support for serverless platforms is now built into Radius with the integration of Azure Container Instances (ACI). This enables deploying the same application definition, unchanged, to either a Kubernetes cluster or to ACI. Support for ACI is an initial step towards Radius’ runtime-agnostic vision, allowing an application to be defined once and then deployed across different container platforms while maintaining a consistent developer experience.
In-place control plane upgrades introduced in v0.50.0 with the rad upgrade and rad rollback commands, make it easy to keep Radius up-to-date. This feature includes preflight safety checks that validate cluster health, permissions, and version compatibility before any changes are made. It also includes built-in rollback capabilities for fast recovery as needed.
Usability improvements across multiple releases have improved the developer and platform engineering experience. Key improvements include:
- Radius Dashboard: Platform engineers can publish organization-specific resource types with rich Markdown docs that include details on how and when to use them, where developers can browse documentation in one place instead of trawling CLI output. The environment page shows additional details about the Kubernetes cluster and the cloud provider configuration.
- Radius CLI: Interactive confirmation prompts for destructive operations like rad uninstall kubernetes, rad group delete, and rad app delete that clearly explain what resources will be affected, preventing accidental data loss.

Community and ecosystem

We have had fruitful engagements with the community through various events and contributions. Our community has grown to ~883 members engaging on Discord and ~864 contributions to a wide range of areas, including some significant features that unblocked specific user scenarios.

Key community resource type contributions:

MySQL Resource Type and Kubernetes Recipe contributed by Andrew Matveychuk.
Neo4j Resource Type and Kubernetes Recipe contributed by Nick Beenham.

Community events and talks:

KubeCon EU 2025 session with Millennium BCP showcased Radius as the IDP application layer, including live multi-cloud demos and curated resource catalogs.
KubeCon US 2024 BackstageCon session showing how Radius integrates with Backstage to visualize environments and deployed applications.
Mark Russinovich’s community presentation on Radius Resource Types outlining the extensibility feature and how platform teams can share reusable abstractions across organizations.
Microsoft Build 2025 session with Mark Russinovich spotlighting how Radius aligns developers and platform engineers on real-world deployments.

What’s next

Extending Radius to even more serverless container runtimes with support for AWS Elastic Container Service (ECS) and Azure Container Apps on the roadmap.
Air-gapped environment support with offline installation, configuration, and upgrades so organizations with strict security requirements can vet and cache packages and control dependency versions without internet access.
Radius Resource Types for AI workloads. As AI reshapes both applications and software delivery workflows to include developers pairing with agents and services that spans beyond Kubernetes, hosted models, databases, queues, and storage, platform engineers must keep both developers and agents aligned with security, cost, and operational guardrails. Check out this blog post on how you can future proof your AI applications with Radius Resource Types. More updates coming soon.

Thank you

Thank you to every maintainer, contributor, speaker, and demo author who invested time in Radius. The result of your efforts are what we celebrate today.

Learn more and get involved

We would love for you to join us to help build Radius:

Try the Radius Tutorial
Checkout the Radius roadmap and influence future features at https://aka.ms/radius-roadmap
Join our monthly community meeting to see demos and hear the latest updates (join the Radius Google Group to get email announcements)
Join the discussion or ask for help on the Radius Discord server
Subscribe to the Radius YouTube channel for more demos

Posts: Announcing Radius v0.52.0

Tue, 14 Oct 2025 16:29:59 +0000

Today marks the release of Radius v0.52.0, bringing usability improvements and refinements to enhance your experience with the Radius platform. This release focuses on making key commands more intuitive and user-friendly, while also addressing several important updates under the hood. You can find the full release notes on the Radius GitHub repository.

If you’re new to Radius, it’s an open-source platform for building, deploying, and managing cloud-native applications. To get started, visit the Radius website for an overview, or check out the getting started guide to install Radius and create your first app.

Usability improvements to `rad uninstall kubernetes`

The rad uninstall kubernetes command has been enhanced to provide a more transparent and secure experience. When you run this command, it now lists all the Kubernetes resources that will be deleted and prompts you for confirmation before proceeding. This ensures that you have full visibility into the impact of the operation.

Additionally, the --purge flag has been improved to perform a thorough cleanup of all Kubernetes resources created by Radius. This makes it easier to ensure that your cluster is left in a clean state after uninstalling Radius. For more details, refer to the CLI documentation.

Usability improvements to `rad group delete`

The rad group delete command now includes a confirmation prompt that lists all resources associated with the group before deletion. This safety measure helps prevent accidental deletions by giving you a clear overview of the impact of the operation. For more information, see the CLI documentation.

Upgrading to Radius v0.52.0

Upgrading to Radius v0.52.0 is straightforward. First, refer to the installation guide to update your Radius CLI to the latest version. Then, run the rad upgrade kubernetes command to upgrade your Kubernetes environment. Note that only incremental version upgrades are supported, so ensure you are upgrading from v0.51.0. For detailed instructions, consult the upgrade documentation.

Learn More and Get Involved

We would love for you to join us to help build Radius:

Try the Radius Tutorial
Checkout the Radius roadmap and influence future features at https://aka.ms/radius-roadmap
Join our monthly community meeting to see demos and hear the latest updates (join the Radius Google Group to get email announcements)
Join the discussion or ask for help on the Radius Discord server
Subscribe to the Radius YouTube channel for more demos

Posts: Announcing Radius v0.51.0

Thu, 02 Oct 2025 00:00:00 +0000

Today, we’re excited to announce the release of Radius v0.51.0! This update introduces several enhancements to improve usability, streamline workflows, and address key user concerns. Whether you’re a developer or platform engineer, this release brings meaningful updates to help you manage your cloud-native Applications more effectively. You can find the full release notes here.

If you’re new to Radius, visit radapp.io to learn more about the platform and its capabilities. To get started, check out the getting started guide for step-by-step instructions on installing Radius and deploying your first application.

Purge behavior updated for uninstall command

Radius v0.51.0 introduces an update to the --purge flag for the rad uninstall kubernetes command. When this flag is specified, all Kubernetes resources created by Radius—including resources generated during application deployments—will now be deleted. This enhancement ensures a more thorough cleanup process when uninstalling Radius from your Kubernetes environment. For detailed usage instructions, refer to the CLI documentation.

Progress status feedback added to application deletion command

The rad app delete command has been improved to provide real-time progress status and a confirmation summary during application deletion. This update addresses a common usability issue where longer deletion operations could appear unresponsive. With this enhancement, you’ll now have clear visibility into the deletion process, ensuring a smoother experience. Learn more about this feature in the CLI documentation.

ACI deployments now use dynamic resource group location

Radius has updated its Azure Container Instances (ACI) deployment process to dynamically retrieve and use the resource group’s location. Previously, deployments defaulted to the hardcoded West US 3 region due to early support for ACI NGroups. This improvement ensures that Radius adapts to your resource group’s location, simplifying ACI Environment creation and resource deployment. For more information, see the how-to guide.

Contour ingress controller installation disabled

Radius v0.51.0 disables the automatic installation of the Contour ingress controller during rad install kubernetes and rad init. This change is due to Bitnami’s deprecation of their public container registry, which impacts the availability of Contour images.

If your Applications rely on Radius Gateway resources for ingress functionality, you’ll need to manually install and configure a Contour ingress controller before deploying Gateway resources. For installation guidance, consult the Contour documentation. Additionally, you may find helpful insights in the Contour community discussion.

This change is temporary while Radius evaluates alternative ingress controller options and repository sources.

Upgrading to Radius v0.51.0

To upgrade to Radius v0.51.0, first update your Radius CLI, then run rad upgrade kubernetes. Note that only incremental version upgrades are supported. For detailed upgrade instructions, consult the upgrade documentation.

Learn More and Get Involved

We would love for you to join us to help build Radius:

Try the Radius Tutorial
Checkout the Radius roadmap and influence future features at https://aka.ms/radius-roadmap
Join our monthly community meeting to see demos and hear the latest updates (join the Radius Google Group to get email announcements)
Join the discussion or ask for help on the Radius Discord server
Subscribe to the Radius YouTube channel for more demos

Posts: Announcing Radius v0.50.0

Thu, 18 Sep 2025 00:00:00 +0000

Today marks an exciting milestone for the Radius community with the release of Radius v0.50.0. This release introduces several significant enhancements designed to improve your experience as a developer or platform engineer. Whether you’re upgrading an existing installation or exploring Radius for the first time, this release has something for everyone. You can find the full release notes here. If you’re new to Radius, visit our getting started guide to learn how to install Radius and create your first app.

Introducing in-place upgrades

Radius v0.50.0 introduces support for in-place upgrades, making it easier than ever to keep your control plane up to date. With the new rad upgrade command, you can upgrade the Radius control plane while preserving your existing Environments and Applications. If something goes wrong, you can roll back to the previous version using the rad rollback command. This feature simplifies the upgrade process and reduces downtime. For more details, see the upgrade documentation.

Additionally, this release integrates preflight checks into the rad upgrade kubernetes command. These checks validate your environment before proceeding with the upgrade, helping you avoid potential issues.

Enhancements to Radius Resource Types

Radius Resource Types now support arrays of objects as properties, enabling more flexible and complex configurations. You can also define an enum type to validate inputs before deployment, ensuring that only valid values are used in your configurations.

However, note that the YAML schema for resource type definitions has changed. The name property has been replaced with namespace. For example, when creating a new resource type using rad resource-type create -f types.yaml, the types.yaml file must now include namespace: Radius.Resources instead of name: Radius.Resources on the first line. Be sure to update your existing resource type definitions to align with this change.

Server-side validation has also been added to ensure that resource data conforms to the type schema, providing an additional layer of reliability during deployments.

Offline installation

Radius can now be installed in offline Environments, addressing a key requirement for air-gapped deployments. You can Use the rad install command or the Helm chart to specify the location of Radius Containers via the global.imageRegistry and global.imageTag parameters. For private registry authentication, the global.imagePullSecrets parameter is also supported. These enhancements make Radius more accessible in restricted Environments.

Learn more and Get Involved

We would love for you to join us to help build Radius:

Try the Radius Tutorial
Checkout the Radius roadmap and influence future features at https://aka.ms/radius-roadmap
Join our monthly community meeting to see demos and hear the latest updates (join the Radius Google Group to get email announcements)
Join the discussion or ask for help on the Radius Discord server
Subscribe to the Radius YouTube channel for more demos

Posts: In-place upgrades now available

Tue, 16 Sep 2025 00:00:00 +0000

Up until now, upgrading a Radius installation meant manually redeploying the control plane. This was cumbersome and risked downtime for your internal platform. Beginning with Radius v0.50, we’re excited to announce support for in-place upgrades of the Radius control plane. Using the new rad upgrade command, platform engineers can now upgrade a running Radius control plane to a new version without rebuilding their Environments or disrupting running applications. This enhancement makes it much easier to keep up with new Radius releases in production, thanks to built-in safety checks and a rollback capability.

In this post, we’ll walk through how the new in-place upgrade feature works and how to use the rad upgrade and rad rollback commands to upgrade safely. For a more detailed step-by-step guide, check out the official How-To: Upgrade Radius on Kubernetes and How-To: Rollback Radius on Kubernetes in the documentation.

Upgrading Radius control plane in-place with `rad upgrade`

Performing an in-place upgrade of Radius is straightforward. Here’s a high-level overview of the process:

Upgrade your Radius CLI: First, ensure you have the latest rad CLI (v0.50 or later) installed on your machine. The new CLI version includes the rad upgrade and rad rollback commands. You can verify your CLI version by running:
```
$ rad version
```
Make sure it shows 0.50.0 or later as the version. If not, update the CLI before proceeding.
Run the upgrade command: Once your CLI is up to date, initiate the control plane upgrade with:
```
$ rad upgrade kubernetes
```
This will upgrade the Radius control plane in your Kubernetes cluster to the latest version matching your CLI. The CLI will first run a series of preflight checks (more on this below) to ensure your cluster and current Radius installation are ready to upgrade. If all checks pass, rad upgrade will proceed to perform the upgrade. Under the hood, this triggers a Helm-based upgrade of the Radius containers. The upgrade is applied as a rolling update to minimize downtime—the Radius Pods will be replaced one by one, preserving the system’s state and all your Environment configurations.

Alternatively, if you want to upgrade to a specific version, you can use the --version flag. For instance, to upgrade to v0.50.0:
```
$ rad upgrade kubernetes --version 0.50.0
```
If you omit --version, the CLI upgrades to the same version as the CLI itself.
Verify the upgrade: After the command finishes, you should verify that the control plane is running the new version and everything is healthy. You can check the Radius version again, which should now reflect the upgraded version:
```
$ rad version
CLI Version Information:
RELEASE VERSION BICEP COMMIT
0.50.0 v0.50.0 0.37.4 42e20ccab9001f54cc9c3074fd20016260a37792

Control Plane Information:
STATUS VERSION
Installed 0.50.0
```

Important: Radius currently supports incremental upgrades only. That means you should upgrade one version at a time (e.g. from v0.49 to v0.50). Skipping directly over a version is not supported by rad upgrade and will be blocked by the version check. Always upgrade sequentially and consult the release notes if you are coming from older versions.

Preflight Checks for Safe Upgrades

One of the great things about rad upgrade is that it includes built-in preflight checks to catch any issues before making changes to your cluster. When you run the upgrade command, Radius will automatically validate a number of conditions, such as:

Kubernetes connectivity and permissions: Verifies connection to the cluster and required RBAC permissions
Helm connectivity and installation status: Confirms Radius is installed via Helm and can be upgraded
Version compatibility validation: Ensures the current version can be upgraded to the target version
Cluster resource availability: Checks that there is sufficient CPU and memory available on the cluster for the rolling update (optional warning)
Custom configuration validation: Validates any custom Helm values

If any of these checks fail, the upgrade will stop and inform you of what needs to be fixed. No changes will be made to your cluster unless all preflight checks pass. This gives you confidence that once the upgrade proceeds, it won’t hit a surprise error halfway through.

Rolling Back if Something Goes Wrong

What if you perform an upgrade and encounter an unexpected problem with the new version? In previous releases, you would have been stuck trying to reinstall the old version manually. Radius v0.50 also introduces a rollback mechanism for fast recovery.

If an upgrade doesn’t go as planned, you can simply run this command to roll back to the previous version:

$ rad rollback kubernetes

Or, to roll back to a specific revision, you can the --list-revisions flag to see available revisions:

$ rad rollback kubernetes --list-revisions
Current Radius version: 0.50.0
REVISION CHART VERSION STATUS UPDATED DESCRIPTION
6 0.50.0 deployed 2025-03-25 21:22:09 Upgrade complete
5 0.49.0 superseded 2025-03-25 21:22:09 Upgrade complete
4 0.42.42-dev superseded 2025-03-25 21:22:09 Upgrade complete
3 0.42.42-dev superseded 2025-03-25 21:22:09 Upgrade complete
2 0.42.42-dev superseded 2025-03-25 21:22:09 Upgrade complete
1 0.42.42-dev superseded 2025-03-25 21:22:09 Install complete

Then specify the desired revision number with --revision:

$ rad rollback kubernetes --revision 5

The rad rollback command will revert the Radius control plane back to the last deployed or specified version. Under the hood, it uses Helm’s built-in rollback capability to restore the previously installed release of Radius. Essentially, it redeploys the prior version’s containers and settings, so your control plane goes back to the state it was in before the upgrade was attempted.

A successful rollback means your Environments and Applications should continue working under the old version, just as before. No reconfiguration should be needed—the aim is to quickly get you back to a known good state.

Learn more

For more details on in-place upgrades and rollbacks, check out the following resources in the documentation:

Get involved

We would love for you to join us to help build Radius:

Join our monthly community meeting to see demos and hear the latest updates (join the Radius Google Group to get email announcements)
Join the discussion or ask for help on the Radius Discord server
Subscribe to the Radius YouTube channel for more demos

Posts: Contribute Your First Resource Type and Recipe

Mon, 11 Aug 2025 00:00:00 +0000

Radius helps platform engineers build powerful Internal Developer Platforms (IDPs) with curated resource catalogs that empower developers to build applications that adhere to all enterprise best practices. Key to delivering custom resource catalogs is the Radius Resource Types feature.

Think of Radius Resource Types as the developer’s interface to your platform. They define a contract—a set of properties developers use to provision infrastructure without needing to know the implementation details. Platform engineers then create Recipes—the implementation of that contract—using tools like Terraform or Bicep to deploy and manage the actual cloud resources, ensuring that best practices related to security, compliance, and cost are followed by default.

While Radius ships with a catalog of common resource types, the true power of Radius is unlocked when the community extends it by creating a shared library of Resource Types. Shared Resource Types, enable you and the community to model any service or technology, from a niche cloud service to a complex, multipart web application.

This post explains how to contribute Resource Types and Recipes to the Radius ecosystem, with the goal of enabling a rich, community-driven library that benefits everyone.

Contribution Process Overview

Contributions to the resource-types-contrib repository are categorized into three maturity levels. This allows for a flexible contribution process, where you can start small and collaborate with the community to mature your Resource Type over time.

Alpha: This is the entry point for all new contributions. At this stage, the focus is on sharing your experimental work. You’ll need a valid resource type schema, at least one working Recipe for any platform, basic documentation, and evidence of manual testing.
Beta: As a contribution matures, it can be promoted to Beta. This stage indicates that the Resource Type is well-tested and ready for broader use. Beta requirements include having Recipes for all major platforms (AWS, Azure, Kubernetes) in both Bicep and Terraform, along with automated functional tests.
Stable: The final stage is for Resource Types that are considered production-ready and are officially supported by the Radius project. These contributions have 100% test coverage, are fully integrated into the Radius CI/CD pipeline, and have a designated owner for long-term maintenance.

You can find the detailed requirements for each stage in our contribution guide.

What Can You Contribute?

You can define any resource specific to your own needs or pick a resource type from the list of open issues.

We’d love to see contributions for:

Databases: NoSQL, time-series, or graph databases.
Messaging: Message queues or event streaming platforms.
AI/ML: Model serving platforms or vector databases.
Cloud Services: Niche cloud provider services or multi-cloud abstractions.
Observability: Monitoring, logging, or tracing solutions.

The more diverse the contributions, the richer the Radius ecosystem becomes.

An Example to Get You Started

To showcase what a good contribution looks like, the Radius team has added a Redis Resource type with a Kubernetes Recipe. This alpha-stage contribution provides:

A complete Redis Resource type schema.
Both Bicep and Terraform Recipes for Kubernetes.
Manual testing with a sample application.
Clear documentation for others to follow.

This serves as a template for community driven development. We encourage you to use it as a reference for your own contributions.

Step-by-Step Guide

We’ve structured the process in the resource-types-contrib repository to be as clear as possible, with three maturity levels for contributions: Alpha, Beta, and Stable.

Here’s the high-level process:

1. Set Up Your Contribution

Fork the resource-types-contrib repository and create a directory for your resource type. The structure is simple and documented in our contribution guide.

2. Define Your Schema

Create a .yaml schema file for your resource type. This is the developer-facing interface. Key guidelines are documented in our contribution guide

3. Create Recipes

Develop Terraform and/or Bicep Recipes to deploy your resource. This is the platform-facing implementation. Key guidelines are documented in our contribution guide

4. Document and Test

Create a README.md with an overview, usage instructions, and examples. Most importantly, test your resource type with a real application and provide evidence that it works as expected.

Contribution Checklist

Before you submit a pull request, make sure you have:

✅ A schema following the naming conventions.
✅ At least one working Recipe (Terraform or Bicep).
✅ A comprehensive README.md.
✅ Evidence of successful testing with a sample application.
✅ Clear commit messages.

Filing Issues and Getting Help

Not ready to contribute code? You can still participate!

Propose a New Resource Type: Open an issue in the resource-types-contrib repository to discuss your idea.
Report a Bug: If you find an issue with an existing Resource type, let us know.
Request an Enhancement: For broader ideas, file an issue in the main Radius repository.

Get Started Today!

The future of Radius resource types is community-driven. By sharing your experiments, testing each other’s implementations, and collaboratively improving the ecosystem, we’re building a platform that truly serves the needs of cloud native application developers. As we build out the testing and CI/CD infrastructure for beta and stable contributions, we look forward to collaborating with you to mature your Resource types and Recipes. Your alpha contributions are the first step in a journey of collaborative development. Together, we can promote them through the maturity levels, ensuring they become robust and reliable components for the entire community.

Ready to contribute? We can’t wait to see what you build!

Get Involved with Radius

Resource Types: Check out the tutorial for step-by-step guide on creating Resource Types and Recipes.
Recipes: Learn more about Recipes.
Monthly Community Meetings: Join the Radius Google Group for announcements.
Discord: Connect with us and other contributors on the Radius Discord.
YouTube: Watch demos and tutorials on the Radius YouTube channel.
Docs: Learn more at docs.radapp.io.

Posts: Future Proofing AI Applications via Radius Resource Types

Fri, 18 Jul 2025 00:00:00 +0000

Building Applications in the AI Era

Imagine you’re an enterprise developer building your first AI-powered application. You start with Anthropic’s Claude, ramp on the APIs, write your application code, configure authentication, test the application and successfully deploy it to production. Everything is working great but, three months later, your organization migrates to an entirely different AI model, such as Google Gemini, for better results or for cost optimization. Suddenly, you’re facing days or weeks of refactoring and testing across environments before redeploying the same application using the different model.

This scenario plays out daily in organizations embracing AI. The rapid evolution of AI means today’s technical decisions may not align with tomorrow’s AI requirements and capabilities. So, platform engineers must provide Internal Developer Platforms that make it easy to develop AI applications while enabling them to adapt to changing AI providers and models without extensive rewrites. This challenge isn’t just technical, it’s architectural. How does an IDP enable developers to build applications that remain loosely coupled to an underlying AI model, while providing developers a consistent, simple interface in cases where the underlying models change?

The Application Contract: Separating What from How

The solution lies in establishing a clear contract with developers, a contract that separates developers’ infrastructure requirements from the implementation details of how that infrastructure is configured and deployed. Such an application contract must define a stable interface that remains consistent regardless of the underlying AI provider or model.

Radius Resource Types enable this contract: Platform engineers use Radius to define custom application resources, including AI models. They enable configuration and deployment of those resources via Radius Recipes, which are infrastructure templates in Bicep or Terraform. Developers simply reference the required resources in their application via simple, high-level abstractions. Infrastructure Recipes, in turn, handle all the implementation details and execution of infrastructure configuration and deployment.

This separation enables developers to focus on building applications while platform teams focus on maintaining infrastructure consistency and governance. When business requirements change - a new AI strategy, new compliance rules, cost optimization, or cloud migration - platform teams simply update Recipes without disrupting application development or compatibility.

The Developer Experience: Simple and Consistent Interface

For a developer, that means adding an AI service to their Radius application is as simple as adding a reference to the AI resource provided by their IDP and then setting a few parameters. Instead of diving into cloud provider documentation, wrestling with authentication flows, or configuring service endpoints, a developer just declares their intent with this simple syntax:

The developer has access to an AI model catalog, curated by their platform engineering team - from lightweight TinyLlama for quick prototyping to production-ready GPT 3.5 Turbo and Claude 3 Sonnet for enterprise features. When developers need to experiment with different models, they simply change one parameter.

The best part is that Radius makes it simple to connect a given container in your application to an AI service. No more wrestling with API keys, endpoints, or different authentication schemes—everything gets injected as environment variables.

And deploy the application with a single command to the environment of choice

rad deploy todolist.bicep --environment azure

rad deploy todolist.bicep --environment aws

For production deployments, teams typically embrace GitOps workflows. Radius seamlessly integrates into these existing workflows, supporting GitOps tools like Flux and with planned support for Argo CD in the future. This means your AI applications can be deployed and managed through the same CI/CD processes your team already uses, maintaining consistency with your broader deployment strategy.

Whether your platform team-provided Recipes provision Azure Cognitive Services, AWS Bedrock Claude models, or tomorrow’s next-generation AI provider, this application contract never changes. The developer experience remains constant while the infrastructure beneath evolves freely. Radius Recipes handle the complexity of authentication, rate limiting, and service configuration automatically.

While Radius mitigates developer exposure to the complexity of infrastructure configuration and deployment, some changes in application runtime may still be necessary. For instance, switching from GPT 3.5 Turbo to Claude 3 Sonnet will require modifying how your runtime code interacts with the model. To abstract your runtime code, use Dapr’s Conversation building block, which provides a single API for calling underlying LLMs. It can be used alongside Radius Resource Types to ensure both infrastructure deployments and the application runtime code is LLM agnostic.

The Platform Engineering Experience: Orchestrating the Experience Behind the Scenes

To enable the developer experience described above, platform engineers work behind the scenes crafting the resource catalog and Recipes that transform abstract developer requests into concrete cloud/platform resources while maintaining the application contract.

Platform engineers define the schema definition for the aiModels resource type, specifying the parameters developers can use to request AI services. They then implement Recipes using Bicep or Terraform that deploy the infrastructure. Recipes use the input context provided by the developer to provision the necessary resources and return output values in a standardized format that Radius can inject into the application.

The Kubernetes Recipe - When a developer requests a TinyLlama model, the Kubernetes Recipe deploys a containerized service that downloads the TinyLlama model binary, configures authentication, and outputs the necessary values needed for the application to connect.

The Azure Recipe - When a developer requests GPT 3.5 Turbo model, the Azure Recipe deploys Cognitive Services, configures authentication, and outputs the necessary values needed for the application to connect.

The AWS Recipe - When a developer requests Claude 3 Sonnet model, the AWS Recipe handles the entirely different world of IAM roles and Bedrock permissions and outputs the necessary values needed for the application to connect.

When the next breakthrough AI service emerges or when new compliance requirements arise or when cost optimization opportunities appear from hosting providers, platform engineers can implement the requirements at the Recipe level without disrupting development workflows.

Check out the Radius Todo List Application which includes an AI feedback feature, demonstrating this approach in practice.

Get Involved

We would love for you to join us to help build Radius:

Try the Radius Todo List Application
Check out the Radius Resource types tutorial
Join our monthly community meeting to see demos and hear the latest updates (join the Radius Google Group to get email announcements)
Join the discussion or ask for help on the Radius Discord server
Subscribe to the Radius YouTube channel for more demos

Posts: Introducing Radius Resource Types

Tue, 17 Jun 2025 00:00:00 +0000

The Radius maintainers and community have been hard at work enabling platform engineers to build internal developer platforms that are application-centric with a great developer experience. This week Radius launched Radius Resource Types, reinforcing its core mission to decouple application definitions from underlying infrastructure.

Enterprises integrating Radius into their internal developer platform tell us they need to customize the API for common resource types such as a PostgreSQL database to simplify the developer experience (allowing developers to select T-shirt sizes, for example). Others want to create abstract resource types such as a web service that may have a reverse proxy, an application container, and an in-memory cache all encapsulated in one single type. Radius Resource Types enable platform engineers to accomplish these exact scenarios. Platform engineers now have complete flexibility in defining the resources developers use in their applications and, separately, the implementation of those resources using Terraform configurations or Bicep templates (referred to generally as Recipes in Radius).

This is a major step forward for platform engineering. Platform engineers gain greater control over the implementation and deployment of cloud resources. Ensuring security, compliance, and cost management best practices are followed is significantly easier. Developers can now work with higher-level, familiar abstractions defined by their organization, simplifying their workflow and reducing cognitive load. They no longer need to learn multiple infrastructure as code languages.

Resource Types: The developer’s interface

Radius ships with a catalog of common resource types. This includes core types such as Containers, Gateways, Secrets, and Volumes, but also open-source resource types including MongoDB, Redis, RabbitMQ, and others. Each resource type has a set of properties developers can specify when defining their application.

For example, the MongoDB resource type has properties for the database name, the host name, the port, and the username. These properties are the interface between the application and the internal developer platform. They constitute the contract between developers and platform engineers.

This interface insulates developers from the infrastructure implementation. They no longer need to know how to deploy their containers to Kubernetes and their database to AWS or Azure. They no longer need to learn Helm and Bicep, CloudFormation, or Terraform.

However, until today, these resource types were predefined, immutable, and built into Radius. All this changes with Radius Resource Types. Platform engineers can now create new resource types with custom APIs, opening up a wide array of new capabilities. For example, platform engineers can now:

Create resource types for application components that do not ship with Radius. For example, a resource type could be created for an OpenAI model.
Modify the API for existing resource types. For example, a T-shirt size (S, M, L) could be added to one of the existing database resources such as MongoDB so the developer can specify the size of the database.
Create more abstract resource types such as a web service, or a functions-based application that only requires the developer to provide a container image for a full application to be deployed.

Radius Resource Types are modeled using an OpenAPI schema in a YAML file. If you have created a Kubernetes Custom Resource Definition (CRD) before, Radius Resource Types will look familiar. For example, here is resource type definition for an OpenAI model:

types.yaml:

namespace: Radius.Resources
types:
 openAIModels:
 apiVersions:
 '2023-10-01-preview':
 schema:
 type: 'object'
 properties:
 environment:
 type: string
 description: The Radius environment, typically set by the rad CLI
 application:
 type: string
 description: The application which the resource is associated with
 capacity:
 type: string
 description: The capacity of the API, valid values are S, M, or L
 apiKey:
 type: string
 description: The key that can be used to connect to the API
 readOnly: true
 apiVersion:
 type: string
 description: The version of the OpenAI API
 readOnly: true
 deployment:
 type: string
 description: The deployment name, used by the OpenAI SDK to connect to the API
 readOnly: true
 endpoint:
 type: string
 description: The endpoint URL of the OpenAI API
 readOnly: true
 required:
 - environment
 - capacity

Let’s walkthrough this resource type definition. By convention, resource type definitions are stored in a file named types.yaml.

namespace: Radius.Resources

The namespace is just a namespace for the resource type. In practice, it is recommended to use Radius.Resources for all resource types. For advanced users, the namespace can be any string in the format Parent.Child (Radius uses Applications.Core for the built-in resource types).

types:
 openAIModels:

Multiple resource types can be listed under types. openAIModels is the name of the resource type. By convention, Radius Resource Types are camel-case and plural.

 apiVersions:
 '2023-10-01-preview':
 schema:
 type: 'object'
 properties:

This defines our API version. API versions in Radius are in date form with an optional -preview suffix. Today, resource types can only have a single version, but in the future, adding additional versions with a different schema will be possible. Note than when developers add resources to the application definition, the API version must always be specified.

 environment:
 type: string
 description: The Radius environment, typically set by the rad CLI
 application:
 type: string
 description: The application which the resource is associated with

These two properties are Radius-specific and should be on every resource type. The environment property is typically set by the Radius CLI when the application is deployed. The application property is set by the developer in the application definition.

 capacity:
 type: string
 description: The capacity of the API. Valid values: 'S', 'M', 'L'

capacity is the only property that the developer needs to set. Later you will see that capacity is a required property.

When the developer is adding an OpenAI model to their application using VS Code, the developer sees the description of the capacity property.

 apiKey:
 type: string
 description: The key that can be used to connect to the API
 readOnly: true
 apiVersion:
 type: string
 description: The version of the OpenAI API
 readOnly: true
 deployment:
 type: string
 description: The deployment name, used by the OpenAI SDK to connect to the API
 readOnly: true
 endpoint:
 type: string
 description: The endpoint URL of the OpenAI API
 readOnly: true

The apiKey, apiVersion, deployment, and endpoint, are all read-only properties meaning the developer cannot set these properties in the resource definition (notice they are not in the screen shot above).

These read-only properties are set by the Recipe after the resource gets deployed. The developer can, however, reference these properties in the application definition. For example, this container has environment variables set using properties from an openAIModels resource.

todolist.bicep:

resource frontend 'Applications.Core/containers@2023-10-01-preview' = {
 name: 'frontend'
 properties: {
 ...
 container: {
 ...
 env: {
 CONNECTION_AI_ENDPOINT: {
 value: openai.properties.endpoint
 }
 CONNECTION_AI_DEPLOYMENT: {
 value: openai.properties.deployment
 }
 CONNECTION_AI_APIKEY:{
 value: openai.properties.apiKey
 }
 CONNECTION_AI_APIVERSION:{
 value: openai.properties.apiVersion
 }
...

Finally, the remainder of the resource type definition YAML file is:

 required:
 - environment
 - capacity

This specified that only the environment and capacity properties are required to be set by the developer.

Recipes: The platform engineer’s implementation

The resource type definition discussed above is only the interface for a resource type. The implementation for deploying this resource is completely separate and not exposed to developers. If you are familiar with Radius, you know that Radius uses Recipes and Environments to determine how to deploy a resource. Radius Resource Types uses the same concepts.

In this example, the openAIModels resource type is used by developers in their application definitions on the left. On the right, the platform engineer has created two Radius Environments. Notice that the same Terraform configuration for deploying the OpenAI model is used for both the test and production environments. While the same configuration file is used, it uses the parameters passed by Radius to determine the proper deployment configuration. The Terraform configuration has several variables set by Radius automatically, but platform engineers can add additional parameters such as production=TRUE in this example.

Composite Recipes

Radius Resource Types also introduces a powerful new concept of composite Recipes. In the previous OpenAI example, the recipe deployed a single resource. But recipes are much more powerful than that. With composite Recipes, platform engineers can model abstract resource types then define a Recipe that is composed of multiple resources.

The resources defined in the composite Recipe can be any type that Radius is aware of including:

Radius core types including Containers, Gateways, Secrets, and Volumes
Resource types built into Radius such as MongoDB, Redis, Dapr Configuration Store, and Dapr State Store
Radius Resource Types defined by the platform engineer
Azure resource types
AWS resource types

For a hands-on example of using a composite Recipe, see the Create a composite Recipe tutorial in the Radius documentation.

Learn More

There are several resources available to learn more about Radius Resource Types:

Mark Russinovich, the CTO of Microsoft Azure and sponsor of Radius, introduced and demoed Radius Resource Types at the June Radius Community Call.
There are two tutorials in the Radius documentation, one for creating a PostgreSQL resource type and a second for creating a composite recipe for a web service resource type.

Get Involved

We would love for you to join us to help build Radius:

Join our monthly community meeting to see demos and hear the latest updates (join the Radius Google Group to get email announcements)
Join the discussion or ask for help on the Radius Discord server
Subscribe to the Radius YouTube channel for more demos

Posts: Deploy your Radius applications to Azure Container Instances

Tue, 03 Jun 2025 08:00:00 -0800

An important part of the Radius vision is to be platform agnostic, and that includes the underlying compute such that Radius can deploy the same application across different compute platforms. Thus, it’s always been a goal to support additional container runtimes beyond just Kubernetes. That’s why we’re excited to share that Radius now supports deploying your applications to additional container platforms, beginning with Azure Container Instances. This integration provides Radius users with a serverless container compute option that enables platform engineers to build developer platforms that are decoupled from specific container runtimes while still benefiting from the Radius application-centric approach and separation of concerns.

To see a demo of this feature, check out the recording of Mark Russinovich’s Inside Azure Innovations session from the Microsoft Build 2025 event

In this post, we’ll walk through at a high-level how to deploy your Radius applications to Azure Container Instances, as well as explore specific details behind the integration. For a more detailed guide, check out the How-To: Deploy an Application to Azure Container Instances guide in the Radius documentation.

What is Azure Container Instances?

Azure Container Instances (ACI) is a serverless container platform in Microsoft Azure that allows users to run containerized applications without managing underlying infrastructure, such as virtual machines or complex orchestration systems. It provides a lightweight, unopinionated compute environment where containers can be deployed quickly, starting in seconds, with configurable CPU and memory resources. ACI is well-suited for cloud-native applications, task automation, build jobs, or any scenario where a lightweight, fast-starting container is beneficial without the overhead of managing a full orchestration system. To learn more about ACI, check out the official documentation from Azure.

Why ACI with Radius?

We chose to integrate ACI first because the Radius maintainers wanted the first expansion beyond Kubernetes to be into a serverless compute platform. Because ACI offers basic, unopinionated building blocks of compute, it provides us with more flexibility in building the integration in an extensible way that covers all the compute primitives available in Kubernetes today. Hopefully, this allows us to better learn how to model the extensibility of Radius core to pave the way for expansion into other container platforms like AWS Elastic Container Service and beyond, including into more opinionated or specialized compute offerings like Azure Functions or AWS Lambda.

Deploying to ACI using Radius

Note: This section provides a high-level overview of the deployment process. For a step-by-step guide, see the How-To: Deploy an Application to Azure Container Instances guide in the Radius documentation.

To deploy your Radius applications to ACI, you’ll first need to ensure you have an Azure provider configured and registered with your Radius control plane. If you haven’t set up Radius yet, you can install it using the rad CLI and connect it to your Azure subscription. For detailed instructions, refer to the Radius installation and Azure provider guides.

Create an ACI environment

Once your Azure provider is set up, you can create a Radius Environment that is configured to ACI for its underlying compute. This environment will be the deployment target for your applications bound for ACI. Creating the ACI environment is the same as creating any other environment in Radius, except that you’ll specify ACI as the compute platform along with other needed configurations in the environment definition file, for example:

resource env 'Applications.Core/environments@2023-10-01-preview' = {
 name: 'aci-demo'
 properties: {
 compute: {
 kind: 'aci'
 // Replace value with your resource group ID
 resourceGroup: '/subscriptions/<>/resourceGroups/<>'
 identity: {
 kind:'userAssigned'
 // Replace value with your managed identity resource ID
 managedIdentity: ['/subscriptions/<>/resourceGroups/<>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<>']
 }
 }
 providers: {
 azure: {
 // Replace value with your resource group ID
 scope: '/subscriptions/<>/resourceGroups/<>'
 }
 }
 }
}

Note that a managed identity is required for ACI deployments. If you choose to utilize a user-assigned managed identity, then you need to ensure it is assigned to the Contributor and Azure Container Instances Contributor roles on the subscription and resource group where the ACI containers will be deployed.

Then, just like any other Radius environment, you deploy this ACI environment using the rad deploy command. When Radius creates and deploys the environment, it will provision the relevant Azure resources required to host your applications in ACI, including the virtual network, internal load balancer, and network security group.

Define and deploy your application

With your environment ready, you can proceed to deploy your application to ACI without changing how you define your applications in Radius. Your Radius application definition includes your container specifications, environment variables, and any required connections to other resources. The beauty of Radius is that the application definitions remain consistent regardless of whether you’re targeting Kubernetes or ACI.

Once your application is defined, you can deploy it using the rad deploy command, specifying ACI as your target platform.

For example, if you have an application defined in a Bicep file named app.bicep, you can deploy it to your ACI environment like this:

rad deploy ./app.bicep --environment aci-demo

Alternatively, if you have a workspace set up for ACI, you can deploy your application using the workspace flag:

rad deploy ./app.bicep --workspace aci-workspace

Once your deployment completes, you can run the rad app graph command in your terminal to view resources that were provisioned for your application:

Displaying application: demo-app
Name: frontend (Applications.Core/containers)
Connections:
gateway (Applications.Core/gateways) -> frontend
frontend -> database (Applications.Datastores/redisCaches)
Resources:
frontend (Microsoft.ContainerInstance/containerGroupProfiles)
frontend (Microsoft.ContainerInstance/nGroups)
frontend (Microsoft.Network/loadBalancers/applications)
frontend (Microsoft.Network/virtualNetworks/subnets)
Name: gateway (Applications.Core/gateways)
Connections:
gateway -> frontend (Applications.Core/containers)
Resources:
gateway (Microsoft.Network/applicationGateways)
gateway-nsg (Microsoft.Network/networkSecurityGroups)
gateway (Microsoft.Network/publicIPAddresses)
gateway (Microsoft.Network/virtualNetworks/subnets)
Name: database (Applications.Datastores/redisCaches)
Connections:
frontend (Applications.Core/containers) -> database
Resources:
cache-vxkt2iou25nht (Microsoft.Cache/redis)

The entire process leverages Radius’s application-centric approach, allowing you to focus on defining what your application needs rather than the underlying infrastructure details specific to ACI.

How it works

Currently, ACI support is hardcoded as imperative Go code in the Radius core codebase, including the API, Recipes, data model, and other components. The Environment and Container resource schemas were updated to include ACI-specific properties. If you’re interested in diving deeper into the implementation details, you can refer to the code changes in PR #9436.

ACI NGroups

The Radius integration leverages the ACI NGroups functionality, which provides a single NGroups API call to create and maintain N number of container instances using a common template. This type of orchestration capability made it possible to build the integration necessary to enable deployment of application containers and NGroups resources to ACI using Radius.

Azure resources provisioned by Radius

Behind the scenes, Radius handles the translation of your application model into the appropriate Azure resources, including container groups and networking components, and provisions them accordingly on your behalf:

Load balancer: ACI requires an internal load balancer to manage traffic to the container instances. Radius provisions a load balancer that routes traffic to your application containers.
Virtual Network: ACI requires a virtual network for networking and security. Radius provisions a virtual network and subnet for your ACI deployments.
Network Security Group: ACI deployments require a network security group to control inbound and outbound traffic. Radius creates a security group with appropriate rules based on your application requirements.
Container Group Profiles: ACI supports container group profiles, which allow you to define common settings for multiple container groups. Radius sets up these profiles based on your application definitions, enabling consistent configurations across deployments.
Container NGroups: Radius creates container NGroups to manage multiple instances of your application containers.
Container Instances: The actual container instances are created based on your application definitions, including the container images, environment variables, and resource requirements.

What’s Next?

This initial release of ACI support in Radius is just the beginning. The vision is to implement a compute platform extensibility model that allows Radius to support additional container runtimes in a more lightweight, flexible, and declarative way in lieu of the current imperative code.

To learn more about or provide feedback on this new compute platform extensibility model, check out the Compute Platform Extensibility design document currently in progress.

Redesigned compute platform extensibility model

With the way ACI integration is currently implemented through imperative code, it is not readily extensible for other platforms. Expansion into each new platform requires intimate knowledge of the Radius codebase in order to make the necessary changes to support the new platform. To address this, we plan to refactor the ACI integration to make use of Radius extensibility features that leverage Radius Recipes to implement the ACI (and other platforms going forward) integration in a more declarative and extensible way.

This new design will enable:

Architectural separation of Radius core logic from platform provisioning code
Community-provided extensions to support new compute platforms without Radius code changes
Consistent platform engineering and developer experience across all resource types

Support for platform-specific capabilities

As a part of the new extensibility model, we plan to enable support for Radius users to access platform-specific capabilities in their applications. This means that while Radius will continue to provide a consistent application model across different platforms, users will also be able to leverage unique features of each platform when targeting deployments to applicable environments. For example, Radius users should be able to deploy to confidential containers when targeting the deployment to an ACI environment.

Learn more and contribute

We would love for you to join us to help build Radius:

Review and provide feedback on the Compute Platform Extensibility design document
Let us know what compute platforms you would like to see supported in Radius by commenting on the Compute Platform Extensibility roadmap item
Join our monthly community meeting to see demos and hear the latest updates (join the Radius Google Group to get email announcements)
Join the discussion or ask for help on the Radius Discord server
Subscribe to the Radius YouTube channel for more demos

Posts: Platform Engineering : Integrating Radius into your GitOps Flux workflow

Tue, 20 May 2025 08:00:00 -0800

GitOps is an approach to managing infrastructure and applications using Git as the single source of truth and has become quite popular in the DevOps and Platform Engineering disciplines. This approach provides several benefits - including declarative management of infrastructure definitions and auditable change logs. Radius fits nicely into this workflow, allowing you to define your applications and infrastructure with Radius and then use GitOps to deploy and manage them across your deployment platforms.

Radius has built first-class support for Flux, a GitOps tool designed to work with Kubernetes and provides a powerful set of features for managing applications and infrastructure through Git.

In this post, we’ll explore how to deploy and manage Radius applications using Flux, how to integrate Radius into your GitOps workflow, and technical specifics on how this integration works. For a step-by-step integration guide for Radius and Flux, check out see How-To: Set up Radius with Flux in the Radius documentation.

Overview of Radius + Flux

In a typical GitOps workflow using Flux, you would have one or more Git repositories that contain your application and infrastructure definitions. These definitions are Kubernetes manifests, Helm charts, or other formats that Flux can understand. When you make changes to these definitions in Git, Flux automatically detects the changes and applies them to your Kubernetes cluster.

Since Radius aims to be deployment platform agnostic, its application and infrastructure definitions are written in Bicep and Terraform, which is not natively supported by Flux. However, the first-class integration we have built brings the needed support in Flux to allow for defining applications and infrastructure with Radius, and then using Flux to deploy and manage them.

Using Radius with Flux

Note: This section is a high-level overview of the integration. For a step-by-step guide, see How-To: Set up Radius with Flux in the Radius documentation.

As with any GitOps workflow, you will need to set up a Git repository that contains your application and infrastructure definitions. To enable Radius in this workflow, you will also need to include a radius-gitops-config.yaml file in the root of your repository. Radius applications and infrastructure are defined using a root Bicep file, so the radius-gitops-config.yaml file will contain a list of Bicep files that define your applications and infrastructure:

radius-gitops-config.yaml

config:
 - name: todolist.bicep # The name of the Bicep file that defines your application
 params: todolist.bicepparam # Optional: Parameter file for the Bicep file
 resourceGroup: default # Optional: The Radius resource group to deploy the resources to
 namespace: todolist-app # Optional: The Kubernetes namespace to deploy the resources to
 - name: anotherbicepfile.bicep # Can optionally specify multiple Bicep files to deploy and manage.

Configuring Flux

Aside from the radius-gitops-config.yaml file, everything else can stay the same as a typical Flux setup. You will need to set up a Git repository and configure Flux to watch that repository. You can do this using the Flux CLI or by applying the necessary Kubernetes manifests.

Note: When installing Flux using the flux bootstrap or flux install commands, ensure that the --network-policy false flag is specified for testing, or that the network policy is configured to allow access from radius-system namespace to the source controller. For more information on the network policy, see the Flux documentation.

Configuring Radius

The Flux integration with Radius is built into the Radius control plane. Everything is configured automatically when you create a GitRepository resource in your cluster. The Radius Flux controller will watch for changes to the GitRepository resources and trigger the necessary actions in Radius. Any changes to the files in the repository will be detected by Flux, and then Radius will create, update, or delete the necessary resources in the cluster. Now you can use Radius to define your applications and infrastructure, and then use Flux to deploy and manage them on Kubernetes.

How does this work?

To enable this integration, we have built new Kubernetes controllers that work together to watch for changes in the Git repository and trigger the necessary actions in Radius. These new controllers are built into Radius — you do not have to configure anything other than placing the radius-gitops-config.yaml file in your repository root.

Radius Flux Controller

The Radius Flux Controller [Code] [Design] watches Flux GitRepository resources on the cluster. When a new GitRepository resource is created, the controller will read the contents of the repository. If it contains a radius-gitops-config.yaml file, the controller will parse the file and create a new DeploymentTemplate resource for each application defined in the radius-gitops-config.yaml file. DeploymentTemplate resources are a new resource type that we have created to represent the deployment of a Radius application.

DeploymentTemplate Controller

The DeploymentTemplate Controller [Code] [Design] watches for changes to DeploymentTemplate resources. When a DeploymentTemplate resource is created, updated, or deleted, the controller will submit the necessary operations and data to the Radius control plane to create, update, or delete the application and its resources.

Extensibility

The design of this feature in Radius is intentionally pluggable to allow for future extensibility. We have built the first-class support for Flux first, but the design allows for other GitOps tools to be integrated in the future.

ArgoCD

Similar to Flux, ArgoCD is another popular GitOps tool for Kubernetes. The design of the Radius GitOps integration allows for ArgoCD to be integrated in the future. We have a GitHub issue open to track the progress of this integration, so if you are interested in this work or would like to contribute, please feel free to comment on the issue.

Using the existing design, ArgoCD could integrate with Radius in a similar way to Flux. ArgoCD would watch for changes to the remote Git repository, and some replacement for the radius-flux-controller would be responsible for creating and updating the DeploymentTemplate resources in the cluster. As long as this DeploymentTemplate resources is created and updated when the Git repository changes, Radius will handle the rest of the deployment process.

One idea is to use ArgoCD’s Config Management Plugins to watch for radius-gitops-config.yaml files in the Git repository. When a new radius-gitops-config.yaml file is detected, ArgoCD would create a new DeploymentTemplate resource in the cluster. This would allow for a similar integration to the one we have built for Flux. We would love to hear your thoughts on this idea, so please feel free to comment on the GitHub issue, and come join us and contribute if it interests you!

Conclusion

Integrating Radius into your GitOps workflow brings out the best of both worlds: the power of Radius for defining and managing applications and infrastructure, and the benefits of GitOps for managing those definitions in a declarative and auditable way. This integration allows you to use Radius to define your applications and infrastructure, and then use Flux to deploy and manage them on Kubernetes.

For more detailed information and step-by-step guides, refer to How-To: Set up Radius with Flux in the Radius documentation.

Learn More and Contribute

The Radius maintainers are excited to continue collaborating with the open-source community to grow its feature set and welcome all contributions from the community.

We’re looking for people to join us! To get started with Radius today, please see:

Start using Radius with the getting started guide.
Explore the open-source code repositories.
Engage with the community.

Posts: Platform Engineering with Radius to build application-centric IDPs

Tue, 13 May 2025 00:00:00 -0800

Very early in my career I worked on a long-forgotten system called the HP-3000. I wrote batch processing applications in Pascal to process financial transactions. Then I transitioned to being a web application developer. Moving from the world where each batch application had a single executable and maybe a few shared libraries to the world of web applications was a big change. I remember trying to wrap my head around how it all worked. There were so many different applications all communicating with other applications. Of course, I quickly learned that it was a simple model-view-controller pattern, and the application was just a collection of binaries and HTML templates.

Roll forward twenty-five years and developers today have the same experience, just on steroids. Cloud-native applications are composed of so many resources—containers, pods, services, databases, message queues, blob storage, secrets, and so on. And of course if you look at the cloud infrastructure needed to host these applications, it gets incredibly complex very quickly.

When I look at the AWS console or a resource group in the Azure portal, I most definitely do not see anything resembling what I would traditionally consider an application. For example, here is what the Azure portal looks like after deploying a moderately complex application, TraderX.

I see lots of stuff TraderX depends upon, but where is the TraderX application? Maybe the cool new Kubernetes GUI, Headlamp, will give us a better view of my application?

Even on the Workloads tab, there is no application. I would show you the AWS console, but you all know what that’s going to be like. As time goes on and technology progresses our applications have become more complex, more distributed, and harder to define.

Compounding this trend, the platforms we use to run our applications have also gotten more complex, more distributed, and less easy to define. Modern cloud platforms including AWS, Azure, Google Cloud, and Kubernetes were built bottom-up and infrastructure centric. But developers build applications top-down and user centric.

What if, instead of seeing infrastructure components in your cloud console, or Kubernetes Pods and Services, we had a console that showed developers and operators their applications?

That’s why we built Radius: To make it easy for Platform Engineers to ensure their IDPs give developers and operators a more application-centric experience.

Radius provides platform engineers an open-source, cloud agnostic, application platform. Radius can be integrated into internal developer platforms (IDPs) to give developers a more application centric experience. For more context regarding how Radius relates to other open-source projects used by platform engineers, please see Platform Engineering with Radius at KubeCon London 2025

Application Centric Developer Experience with Radius

Let’s take a look at the specifics of the application-centric developer experience when creating a Radius application. Radius provides an application-centric experience in two basic ways:

Radius allows developers to focus entirely on their application without intermingling cloud infrastructure concepts within their application. Specifically, Radius enables defining an application once and deploying it across clouds (private cloud, AWS, Azure), without the developer having to understand the nuances of each. Radius also provides consistent syntax for defining application resources whether they run in the cloud (like AWS MemoryDB) or on Kubernetes (like a frontend container).
An output of every Radius application deployment is an application graph, just like the graph of the TraderX app shown above. So, the developer and other members of an enterprise application team all understand exactly what the application is, all of it’s software and infrastructure components sand how they are all connected. The graph makes very clear what the application is and all of its component dependencies.

To better understand this application-centric experience, imagine you are an enterprise application developer very familiar with writing and containerizing runtime application code but not familiar with cloud infrastructure deployment and configuration. You want to just describe your application and deploy it to whatever cloud your company prefers, whether private-cloud, AWS or Azure. To provide this experience in a real-world scenario, your infrastructure operator would configure your Radius environment to enable the following developer experience. More on this later. For now, we’ll just walk through a simple example that you can try out yourself at the Radius Getting Started Guide.

We’ll start with the description of a very simple ToDo list application that includes only two resources: a frontend container and a Redis cache. These resource types are both natively supported in Radius. (In a future post, we’ll explain how to extend Radius by adding your own custom resource types). Here’s the Radius application description, which is written in the Bicep language:

//This is a Radius application file named app.bicep.

// Import the set of Radius resources (Applications.*) into Bicep
extension radius

@description('The app ID of your Radius Application. Set automatically by the rad CLI.')
param application string

//This is a frontend container named 'demo'
resource demo 'Applications.Core/containers@2023-10-01-preview' = {
 name: 'demo'
 properties: {
 application: application
 container: {
 image: 'ghcr.io/radius-project/samples/demo:latest'
 ports: {
 web: {
 containerPort: 3000
 }
 }
 }
//The following connection makes it easy to connect this frontend container 
// to the database defined further below
 connections: {
 redis: {
 source: db.id
 }
 }
 }
}

param environment string
//This is the definition of the database resource, named 'db'.
//It is a Redis cache, which is a type of datastore.
resource db 'Applications.Datastores/redisCaches@2023-10-01-preview' = {
 name: 'db'
 properties: {
 application: application
 environment: environment
 }
}

You can see the frontend container (demo) in this application is created using the resource key word, which just tells Radius to create an application resource, in this case one of type container. This container has only a few parameters, including a container image file and a container port. The container also includes a Radius “connection,” which is a powerful feature. Connections enable Radius to do a lot of work behind the scenes for the developer, including showing explicit connections in an application graph, like the TraderX application graph pictured above. With connections, Radius also automatically injects details like connection strings and credentials into the container as environment variables. This tells the container how to connect to Redis no matter where Redis is deployed (on-premise, on AWS or on Azure) so the developer doesn’t have to grapple with all of these details.

It’s also very easy for the developer to add a database to this application. The developer creates a resource named db of type redisCaches with only an application and an environment parameter. Per the connection defined in the frontend container above, db is explicitly connected to the frontend container, demo. Notice that even though the container is a kubernetes specific resource and redis is a service that can run in any cloud environment, the syntax for creating both the container and the Redis cache is consistent.

That’s it! Your first Radius application is ready to deploy! But, before we look at the deployment experience, let’s pause to highlight some things you do not see in this Radius application definition: Beyond creating a redis resource named db, there are no infrastructure details. As a developer, you are not concerned about how Redis is configured and deployed, how your application will authenticate to Redis, how Redis connects to your frontend container, or even where Redis will ultimately run (on-premise, AWS or Azure). You just say you need Redis and you need it connected to your frontend container, and Radius uses a feature called Recipes to do the rest. That’s a big reason for why we say Radius provides an application centric experience: Developers focus entirely on their applications, not on the details of underlying infrastructure deployment and configuration.

Now, here’s the deployment experience using the Radius CLI. (In a real world scenario, Radius application deployments would more likely happen via a GitOps tool like Flux or ArgoCD. We’ll discuss Radius integration with GitOps tools in a future post). To deploy this application to, say, your default local environment, from the rad CLI, you would run

rad run app.bicep

The run command deploys the application and it sets up port forwarding so you can:

Browse the applications graph at https://localhost:7007, which is a Backstage based Dashboard that allows you to browse all the details of your Radius application. The application graph is created every time you deploy a Radius application. So, you can always easily see the application you deployed, the resources that make up that application, including all of its dependent infrastructure.
Browse the actual running application at https://localhost:3000.

Let’s first take a look at the application graph at https://localhost:7007.

This application graph shows only two nodes: the frontend container and the Redis cache defined in the app.bicep file above. The two resources are explicitly connected to each other per the connection property discussed above. Radius application graphs are as simple or as rich as the application they describe, as we saw in the TraderX application graph above. Regardless, the graph makes it trivial to visualize any application you have deployed, which contributes to a more application-centric experience for developers and their operator and SRE counterparts.

Navigating to the actual running application at https://localhost:3000, we see

The ToDo list application has a Container Info tab that shows all of the environment variables Radius automatically created inside of the container based on the connection property in the Radius application description. When writing this Radius application, the developer was focused on declaring the intent to have the frontend container and the Redis connected but then Radius took care of these connection details behind the scenes.

Lastly, let’s take a look at the deployment experience for deploying the same todo list application to Amazon Web Services and Azure. This experience is completely consistent with the local deployment above, the developer just changes the target Radius environment for the application deployment. Above the target was a default local environment. Below assumes your Radius environment for Amazon Web Services is named aws, and your environment for Azure is named azure.

To deploy the application unchanged to AWS you would run

rad deploy app.bicep --environment aws

To deploy the application unchanged to Azure you would run

rad deploy app.bicep --environment azure

In both cases, the application is deployed to the target cloud environment without the developer having to make environment specific changes to the application description.

Recipes

The application-centric experience described above is largely enabled by a Radius feature called Recipes. In a future post, we’ll explain Recipes (which are written in either Terraform or Bicep), how they enable the developer experience described above and how they are authored by infrastructure operators.

Conclusion

Radius is an open source, cloud agnostic application platform that you can integrate into your internal developer platform (IDP) to provide an application centric experience for your developers. Radius enables app-centricity in two basic ways:

Radius allows developers to focus entirely on their application without intermingling cloud infrastructure concepts within their application. Specifically, Radius enables defining an application once and deploying it across clouds (private cloud, AWS, Azure), without the developer having to understand the nuances of each. Radius also provides consistent syntax for defining application resources whether they run in the cloud (like AWS MemoryDB) or on Kubernetes (like a frontend container).
An output of every Radius application deployment is an application graph, just like the graph of the TraderX app shown above. So, the developer and other members of an enterprise application team all understand exactly what the application is, all of it’s software and infrastructure components sand how they are all connected. The graph makes very clear what the application is and all of its component dependencies.

To replicate the steps for deploying the simple Radius discussed above, please try the Radius Getting Started Guide.

Learn More and Contribute

If you are a platform engineer, we invite you to try using Radius in your internal developer platform to provide a more application centric experience. We also invite everyone in the open source community to get involved with the Radius project. Your perspective and contributions are immensely valuable.

Join our monthly community meeting to see demos and hear the latest updates (join the Radius Google Group to get email announcements)
Join the discussion or ask for help on the Radius Discord server
Subscribe to the Radius YouTube channel for more demos

Posts: Platform engineering with Radius at KubeCon London 2025

Thu, 24 Apr 2025 08:00:00 -0800

I had a great time at KubeCon London earlier this month presenting and demoing Radius and meeting members of the Radius community! Thanks to everyone for taking time to stop by and chat. It was very fun to meet so many community members in person versus over video conference. 😊

Anyone familiar with Radius will know that platform engineers have become the primary focus for the maintainers. That’s because so many Radius early adopters are platform engineering teams who are integrating Radius into their internal developer platforms (IDPs). A great example is Nuno Guedes and his platform engineering team at Millennium bcp (the largest private bank in Portugal). The Millennium bcp team has integrated Radius into their IDP and have been using it in production since December 2024. Nuno is the head of cloud at Millennium bcp and he and I co-presented on his use of Radius at KubeCon London. To learn more about how the Millennium bcp team is using Radius in their IDP, please check out our joint presentation How Millennium bcp Leverages Radius to Empower Developer + Operator Collaboration (CNCF YouTube channel | Slides from presentation).

Also please check out the Radius YouTube channel where you can see the demos I show in the presentation:

A recurring theme from this presentation and many other conversations that I had at KubeCon is how Radius enables platform engineers to provide an application-centric experience through their IDPs. I have the good fortune to work with so many platform engineering teams from around the world. Those teams have taught me a ton about the problems they are solving via for enterprise application teams via custom IDPs, the challenges they face, and the increasingly rich ecosystem of open-source technologies they leverage in their day-to-day work. This diagram from CNOE (as snipped from the slide deck above) does a great job as a reference architecture including common open-source technologies used to build IDPs. Many platform teams use open-source technologies like Kubernetes for their compute platform, Terraform for infrastructure as code, Backstage as the UI framework for their developer portals, ArgoCD or Flux for GitOps workflows, etc.

Radius maintainers, along with our platform engineering early adopters found common cause around an important concept and technology that is missing in this landscape: the notion of what you can think of as an “application model,” or an “application platform.” That gap matters a lot, because developers live and breathe applications: It’s what they design, build, support. It’s what they reason about in their day-to-day work. But, in the world of distributed systems and cloud native technologies, it’s gotten increasingly difficult to reason about an application as an entity or even agree on what an application is and what its boundaries are. That ambiguity, in addition to the myriad challenges with cloud development, just further increases the cognitive load developers struggle with, which ironically is what IDPs are explicitly designed to reduce. Platform engineers require an open-source project to draw from, along with those illustrated above, that allows them to build an application-centric developer experience. That’s where Radius comes in: Radius is the application model platform engineers use to provide an application-centric developer experience integrated with other key open-source technologies used in their IDPs like Terraform, Flux, and Backstage.

Radius is open-source (CNCF), it is cloud-agnostic and it allows you to create custom application resources tailored precisely to the needs of your developers.

Please watch the KubeCon presentation from Millennium bcp mentioned above. And watch this blog for future posts on how Radius is used by platform engineers in IDPs to:

Provide an application-centric experience for enterprise application developers
Enable better collaboration across application developers and infrastructure operators
Create custom Radius application resources and publish them to a Backstage catalog
Deploy Radius application as part of GitOps workflows using Flux or ArgoCD
Deploy the same Radius application, unchanged, across
- Clouds: on-premises, AWS, and Azure
- Runtimes: Kubernetes and serverless container runtimes like Azure Container Instances and AWS Elastic Container Services

Learn More and Contribute

We would love for you to join us to help build Radius:

Join our monthly community meeting to see demos and hear the latest updates (join the Radius Google Group to get email announcements)
Join the discussion or ask for help on the Radius Discord server
Subscribe to the Radius YouTube channel for more demos

Posts: Radius feature roadmap update

Mon, 21 Apr 2025 08:00:00 -0800

The Radius project maintainers would like to provide a progress update on our feature roadmap to share some of the features that have been released, what’s coming next, and how the community can help shape the future of Radius.

We invite the community to provide feedback on our priorities to jointly grow and enhance Radius. Please bookmark the Radius roadmap for updates on the full set of roadmap priorities.

To see video demos of the latest Radius features, visit the Radius YouTube channel

Recent progress

With early adopters of Radius being primarily platform engineers, GitOps support and the ability to create custom resource types are the two major feature requests. These have been part of the top priorities for Radius, with the recent release of Flux integration and custom resource types coming soon. In addition, Radius contributors have been hard at work in delivering other new features, including support for the Dapr Configuration building block. Other recent accomplishments include a new rad resource-type create CLI command that introduces foundational primitives for resource extensibility, while preparations for migrating to PostgreSQL lay the groundwork for further improvements to the Radius data store. These updates reflect the collaborative efforts of the Radius community to drive innovation and usability.

Support for GitOps using Flux

Radius now has integrated first-class support for Flux, a popular GitOps tool. Flux is designed to work with Kubernetes and provides a set of features for managing applications and infrastructure through Git. To learn more, visit the Radius and GitOps overview and how-to guide for Radius + Flux. You can also view a demo of the Flux features here.

Support for Dapr Configuration Building Block

A new Applications.Dapr/configurationStores resource type is now available to define and deploy the Dapr Configuration building block in Radius. The Dapr Configuration building block allows for dynamic configuration updates, including feature flag management, and is a great addition to the Dapr integration in Radius. To learn more, go to the Dapr Configuration Store resource schema in the Radius documentation. To see a demo of this feature, visit the Radius YouTube channel here.

rad CLI command for creating new resource types

We have added a CLI command rad resource-type create to create new resource-types in Radius. This was added to enable resource extensibility in Radius. The end-to-end functionality of creating and deploying a custom user-defined resource type will be available in a future release. To learn more about these efforts, see the resource types extensibility technical design document. For an early preview, check out the video demo for deploying custom resource types here.

Preparations for using PostgreSQL as the Radius database

In the near future, the Radius data store will be migrated from etcd to a PostgreSQL database. In preparation for this, the Helm chart for installing Radius now includes deploying PostgreSQL to the Kubernetes cluster. You can follow the progress of moving the Radius data store in this issue.

Upcoming priorities

Looking ahead, our feature focus will be on enhancing the extensibility of Radius, starting with the ability to create custom resource types and enabling compute platform portability into serverless container platforms. Scalability and operational improvements are also on the horizon, including control plane upgrades, support for external data stores, and ability to specify additional application configurations.

Custom resource types

Radius currently supports a set of built-in resource types that you can define and deploy in your Radius application. Through custom resource types, Radius will provide an extensibility model where the user can bring their own services or resources and integrate them with Radius. This will enable users to easily define and deploy their own resource types and leverage the other features of Radius such as Recipes and Application Graph to manage their complete suite of resources. Additionally, it will provide an avenue for the open-source community to publish custom resource types and Recipes as community supported assets.

Serverless container platforms

An important part of the Radius vision is to be not only cloud provider agnostic, but also container platform agnostic, and that includes the underlying compute such that Radius can deploy the same application across different compute platforms. Given the importance of serverless infrastructure in the modern application landscape, it is a priority for Radius to support serverless container platforms, in addition to Kubernetes, as the underlying compute platform. Our first foray into this space will be to build support for Azure Container Instances as a compute provider. We wanted our first expansion beyond Kubernetes to be into a less opinionated platform that provides raw compute primitives which allows us to better learn how to model the extensibility of Radius. Our learnings will hopefully pave the way for further expansion including AWS Elastic Container Service and Azure Container Apps in the future.

Control plane upgrades

Today, Radius does not have a safe mechanism for upgrading from one release to another. This enhancement provides users the ability to upgrade from an existing installation to a new release with safeguards in place like data backups, rolling upgrades to minimize downtime, and automatic rollback if something goes wrong with the upgrade. This is a critical feature for production deployments of Radius, and we are working to ensure that users can effortlessly upgrade their control plane installations without losing the stored state of their applications.

External data store

As mentioned above, preparations are underway for enabling the use of PostgreSQL as the Radius data store and implementation is ongoing. This will improve the resiliency of the Radius control plane and make upgrades easier. The technical design is here if you’d like to read about or contribute to this effort.

Additional application configurations

Incremental improvements to the application configuration experience in Radius are also in progress. These include the ability to specify application scaling behavior (such as custom metrics for scaling and setting maximum number of replicas) and the ability to configure HTTP timeouts for gateways. These are community-driven enhancements that will provide users with more control over their applications and improve the utility of Radius across a wider range of production scenarios.

Learn more and contribute

All feedback and contributions are welcome! The community is encouraged to engage with the Radius project in the following ways:

Provide feedback to influence roadmap decisions by commenting on and upvoting existing items
Submit new feature requests to propose new functionality or other issue reports
Review in-progress designs and code
Contribute directly to fix open issues and documentation
Engage with the Radius community via the monthly community calls and Discord

Radius Blog – 2025

Posts: Announcing Radius v0.54

Fixed rad workspace show errors when no current workspace exists

Fixed rad credential show azure command

Upgrading to Radius v0.54

New contributors

Learn More and Get Involved

Posts: Deploy a RAG chatbot app using Radius

Overview of the sample chatbot application

Modeling the chatbot app using Radius

Radius Resource Types and Recipes for dependencies

Radius Application definition

Multi-environment deployment

Governance and guardrails using Radius

Seeing it in action

In summary

Get Involved with Radius

Posts: Announcing Radius v0.53.0

Contour ingress controller installation re-enabled

Improved environment deletion experience

Better Onboarding & Learning Experience

New contributors

Upgrading to Radius v0.53.0

Learn More and Get Involved

Posts: Happy 2nd birthday, Radius!

Year in review: Radius feature highlights

Community and ecosystem

What’s next

Thank you

Learn more and get involved

Posts: Announcing Radius v0.52.0

Usability improvements to rad uninstall kubernetes

Usability improvements to rad group delete

Upgrading to Radius v0.52.0

Learn More and Get Involved

Posts: Announcing Radius v0.51.0

Purge behavior updated for uninstall command

Progress status feedback added to application deletion command

ACI deployments now use dynamic resource group location

Contour ingress controller installation disabled

Upgrading to Radius v0.51.0

Learn More and Get Involved

Posts: Announcing Radius v0.50.0

Introducing in-place upgrades

Enhancements to Radius Resource Types

Offline installation

Learn more and Get Involved

Posts: In-place upgrades now available

Upgrading Radius control plane in-place with rad upgrade

Preflight Checks for Safe Upgrades

Rolling Back if Something Goes Wrong

Learn more

Get involved

Posts: Contribute Your First Resource Type and Recipe

Contribution Process Overview

What Can You Contribute?

An Example to Get You Started

Step-by-Step Guide

1. Set Up Your Contribution

2. Define Your Schema

3. Create Recipes

4. Document and Test

Contribution Checklist

Filing Issues and Getting Help

Get Started Today!

Get Involved with Radius

Posts: Future Proofing AI Applications via Radius Resource Types

Building Applications in the AI Era

The Application Contract: Separating What from How

The Developer Experience: Simple and Consistent Interface

The Platform Engineering Experience: Orchestrating the Experience Behind the Scenes

Get Involved

Posts: Introducing Radius Resource Types

Resource Types: The developer’s interface

Recipes: The platform engineer’s implementation

Composite Recipes

Learn More

Get Involved

Posts: Deploy your Radius applications to Azure Container Instances

What is Azure Container Instances?

Fixed `rad workspace show` errors when no current workspace exists

Fixed `rad credential show azure` command

Usability improvements to `rad uninstall kubernetes`

Usability improvements to `rad group delete`

Upgrading Radius control plane in-place with `rad upgrade`