01—Copilot can turn a repository into an application graph
Microsoft’s Radius project has moved Radius Canvas into public preview inside the GitHub Copilot app, giving developers a visual way to understand an application before they deploy it.
Ask Copilot to show the application graph and Radius analyzes the source code, manifests, and Dockerfiles. It generates a versioned application definition at `.radius/app.bicep`, then opens the modeled application inside Radius Canvas.
The graph represents workloads, routes, backing services, connections, and infrastructure dependencies detected in the repository. That gives the developer something chat alone does not: a visible model of the application that can be inspected, compared, and used again later in the deployment workflow.
02—The model stays beside the code
Radius does not treat the graph as a disposable visualization. The generated application definition is stored with the repository, so it can be versioned alongside the source code.
Each component in the graph can link back to the source file where Radius detected it. A developer can inspect the high-level application shape, select a workload or dependency, and jump back to the code that produced it.
The same application definition is then used for planning and deployment. The model a developer reviews is the model Radius continues to work from, which keeps architecture, code, and deployment connected instead of recreating context at every step.
03—Branch diffs show architectural impact, not just changed lines
One of the strongest features is the Diff view.
Radius Canvas can compare the application model on one branch with another and show which components, connections, and dependencies were added, removed, or modified.
A normal code diff tells reviewers which lines changed. An application-level diff can show that a branch added a new service, introduced a new backing resource, or changed an infrastructure dependency.
Radius can also generate a Markdown summary of the Diff view so those architectural changes can be posted alongside a pull request. That gives reviewers a faster way to understand what a code change means for the shape of the application, not only the files that were edited.
04—The same graph becomes a deployment plan
After modeling the application, Radius Canvas can connect it to a Radius Environment and show a planned deployment.
The Planned view displays the application together with the supporting infrastructure Radius expects to provision for the selected environment. Developers can inspect resources, connections, Radius resource types, and links back to source code and the application definition.
Reviewing the plan does not create cloud resources. Teams can inspect the intended deployment first, then decide whether to proceed.
That keeps the workflow consistent: the modeled view shows what the application is, the planned view shows how its requirements will be satisfied, and the deployed view shows what is actually running.
05—Deployment runs through GitHub Actions
When the developer selects Deploy Application, Radius dispatches a GitHub Actions workflow that provisions the required infrastructure and deploys the application to the chosen Radius Environment.
The workflow is committed to the repository, so it can be reviewed and maintained alongside the code.
Radius also establishes OIDC trust with GitHub Actions for the environment. That lets deployment workflows use short-lived credentials instead of long-lived cloud secrets stored in the repository.
Once the workflow is running, deployment status is visible from Radius Canvas, with a link to the GitHub Actions run for deeper detail. When deployment finishes, the canvas can show the application and resources running in that environment.
07—The preview is focused on containerized apps on Azure
The current preview has a deliberately narrow deployment scope.
Radius Canvas supports containerized applications deployed to Azure, and the setup expects an Azure subscription, an AKS cluster, the Azure CLI, GitHub CLI access, and a repository the developer can write to.
Radius says AWS support is coming soon.
The preview currently focuses on modeling and deploying one application from a single repository, with additional application structures and cloud providers planned for future releases.
That gives the first version a clear path: repository to application model, model to plan, plan to GitHub Actions deployment, and branch changes back into an application-level diff.
The Radius application model also stays in the repository, so platform teams can review how the deployment definition evolves with the code instead of rebuilding that context from scratch. That makes the preview especially relevant to teams experimenting with AI-generated changes: the agent can produce code quickly, while the application graph gives reviewers another surface for checking whether those changes altered services, dependencies, or infrastructure expectations.
08—The Upgrade Feeling
Radius Canvas gives GitHub Copilot something more useful than another chat command: a visible application model.
Source code becomes an application graph. Branch changes become an architectural diff. The same model becomes a deployment plan, and GitHub Actions turns that plan into a real environment using versioned workflows and short-lived credentials.
That makes the repository easier to reason about as a system instead of a pile of files.
As coding agents generate larger changes, tools like Radius Canvas may become increasingly valuable for the step that comes next: helping developers see what the agent actually changed at the application level before they ship it.
That is a useful milestone for the hundredth TUF blog: the coding assistant is starting to expose the system-level consequences of its own work, not just the code it generated.