Radius Canvas is bundled with the radius plugin for the GitHub Copilot app.
It lets you define, visualize, and deploy an
application with Radius without
leaving Copilot. Radius is a cloud-native application platform that helps
developers and platform engineers build and manage applications together.
The radius plugin is available in the github/awesome-copilot plugin catalog.
The Radius canvas runs only in the GitHub Copilot app. Open the app, select Customize in the side menu, and then select Plugins. Search for radius and install the plugin.
Restart your Copilot session after installing so the skills and canvas become available. Use the plugin's three-dot menu to update or uninstall it.
The Radius Canvas UI itself is only available via the GitHub Copilot app. That being said, the Radius plugin bundles other AI tools that may be used independently of the Canvas. See plugins/radius/README.md for what the plugin bundles and how to use it.
NOTE: Radius Canvas is in preview. Send us your feedback: open an issue and tell us what you think.
The GitHub Copilot app is a desktop application for agent-driven development, available on macOS, Linux, and Windows. It is built on the GitHub Copilot CLI and integrates natively with GitHub, so your repositories, branches, issues, and pull requests work out of the box. The app gives you one place to direct AI agents across parallel workstreams and manage the full development lifecycle.
Within the app, a canvas extension
is a shared, interactive surface where people and agents collaborate on a work
artifact. Canvases are bidirectional: the agent updates the canvas as it works,
and you steer, edit, and verify directly on the same surface instead of relying
on chat alone. A canvas opens in the app's right side panel and combines UI
controls for people with agent-callable capabilities. Each canvas extension is a
small package (typically a package.json and an extension.mjs entry file) that
defines the canvas behavior and its capabilities.
Radius Canvas turns your source code into a modeled Radius application, shows that application as a live graph across its lifecycle, and deploys it to your cloud environment, all from inside Copilot. It is organized into three areas:
- Applications. The application graph models the source code in your GitHub
repository and renders it as a live graph with four views:
- Modeled: the application as you've designed it.
- Planned: the application as you want it deployed.
- Deployed: the application as it runs in your environments.
- Diff: what changed between two branches, such as a pull request against
main.
- Environments. An environment is the landing zone that defines where an application deploys. You create an environment for Azure, verify its credentials, and configure the infrastructure your applications run on.
- Deployments. A deployment sends an application to a configured environment. Radius provisions the cloud infrastructure the application needs and runs it through the generated GitHub Actions workflow.
The product logic is UI-agnostic and lives in a shared core (packages/core), so
the same modeling, graph, platform, and workflow-generation logic can back
additional UI surfaces beyond the Copilot canvas in the future.
The plugin also ships five agentic skills, in extensions/radius/skills/. Each one tells the agent how and when to drive a part of the Radius workflow — modeling, graphing, environments, deployment, and deletion — and pairs with the matching canvas actions and tools. See plugins/radius/README.md for what each skill does.
This is a pnpm workspace monorepo. UI-agnostic product logic
lives in a shared core (packages/core), and the Copilot canvas adapter
(packages/adapter-canvas) wires it into the GitHub Copilot app. The core never depends
on an adapter, the Copilot SDK, HTTP, or the DOM; anything that touches the
outside world goes through a port, which keeps the same logic reusable
across future UI surfaces.
See packages/core/README.md for the full architecture
and extension guides, and Contributing for the repository
layout and development workflow.
See Contributing for prerequisites, the repository layout, the build and test workflow, and how to add compute platforms, canvas actions, or new UI adapters.
- ❓ Have a question? - Visit our Discord server to post your question and we'll get back to you.
⚠️ Found an issue? - Open a bug report- 💡 Have a proposal? - Open a feature request
Visit Contributing for more information on how to build, test, and contribute to this repository.
We welcome your contributions and suggestions! One of the easiest ways to contribute is to participate in Issue discussions, chat on our Discord server. For more information on community engagement, developer and contributing guidelines and more, head over to the Radius community repo.
Changesets drives independent plugin versions and changelogs. Every merge to main refreshes each plugin's rolling <plugin>@edge channel. The Release workflow can prepare one plugin or every pending plugin; merging its scope-labelled PR validates the exact version diff, builds behind shared gates, and publishes attested assets on a zero-history releases/<plugin>/v<version> branch tagged <plugin>@<version> — the one tag a stable release writes, and the tag its GitHub release is cut from. GitHub immutable-release enforcement is an optional repository-variable switch. Follow the release runbook to cut one, or see RELEASING.md for the full lifecycle.
Please refer to our Radius Community Code of Conduct.