Project Lattice PRFAQ#11643
Conversation
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
There was a problem hiding this comment.
Pull request overview
Adds a design-note feature specification for the “GitHub Radius” prototype, describing GitHub-native Radius + Copilot integration and end-to-end user journeys (with UI mockups) for deploying a GitHub repo to AWS/Azure.
Changes:
- Add a comprehensive spec document covering user journeys and technical workflow for AWS environment setup and deployment.
- Add/update a UI mockup image referenced by the spec.
Reviewed changes
Copilot reviewed 1 out of 17 changed files in this pull request and generated 7 comments.
| File | Description |
|---|---|
| eng/design-notes/github/2026-03-github-radius-feature-spec.md | New feature spec with user journeys, AWS OIDC/IAM workflow, and deployment UX walkthrough (with mockups + example commands/policies). |
| eng/design-notes/github/2026-03-github-radius-feature-spec/image13.png | Adds a mockup image used by the deployment step in the spec. |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
| 1. The user is taken to the application definition. | ||
|
|
||
|  |
There was a problem hiding this comment.
We should enable some mechanism for users to provide feedback on the generated definition
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
|
|
||
| GitHub Radius continues to use resource types and recipes as the mechanism by which abstract application resources become concrete cloud resources. The Radius `resource-types-contrib` recipe library is reused, now with greater importance. What changes is the expectation of how mature and comprehensive the resource types and recipes must be. | ||
|
|
||
| In Kubernetes-based Radius, the enterprise's platform engineer was expected to either bring their own recipes or substantially customize Radius' recipes. In GitHub Radius, the Radius project is now responsible for ensuring the resource types and recipes are production ready and follow security and cost best practices. Because of this shift, the Radius project will need to invest more resources in the development, testing, and maturing of the existing recipe library. |
|
|
||
| Our objective remains the broad adoption of Kubernetes-based Radius by enterprises. GitHub Radius is targeted at a distinctly different non-enterprise persona. We believe that, with Radius built into the Copilot app, enterprises will gain greater exposure to Radius, which will drive adoption of Kubernetes-based Radius. | ||
|
|
||
| Developers who use GitHub Radius for side projects and prototypes will encounter Radius's application graph, and when they move to an enterprise team with shared infrastructure needs, they will already understand the mental model and advocate for Kubernetes-based Radius. |
There was a problem hiding this comment.
I think we will need a stronger glue point than this. this seems like two separate projects
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
|
|
||
| We do not have concrete plans to ship Repo Radius as a standalone deployment option today. GitHub Radius is the priority. | ||
|
|
||
| **Q25: Why are application definitions no longer in Bicep? Doesn't that go against our objective with Radius?** |
There was a problem hiding this comment.
Missing a crisp, concrete "golden path" example. Suggest adding a simple end‑to‑end scenario showing how a platform team uses this in practice and what improves.
| * Guided credentialing can be implemented in `rad init`. | ||
|
|
||
| These features will be considered as capacity allows, but the primary investment is in GitHub Radius. | ||
|
|
There was a problem hiding this comment.
The FAQ should more directly address "why not alternatives" (Crossplane, Terraform + GitOps, internal platforms, etc). This is critical for credibility with platform engineers.
|
|
||
| **Q25: Why are application definitions no longer in Bicep? Doesn't that go against our objective with Radius?** | ||
|
|
||
| In GitHub Radius, developers no longer define applications in Bicep. Bicep continues to be used under the hood for deployments but the application definition itself is a JSON graph the Radius skills read and write to directly. When a human authored infrastructure, Bicep provided type checking, IDE autocomplete, schema-driven validation, and reviewable text diffs in pull requests. Every one of those capabilities exists because a human is the one typing, and humans make mistakes that a type system can catch before deployment. |
There was a problem hiding this comment.
for Q21 above, is the idea that we can export from json graph -> bicep ? or internally it is bicep -> json graph which is stored and for migrating, we generate bicep again?
|
|
||
| GitHub Radius is a capability inside the GitHub Copilot application that lets developers define, deploy, and operate cloud-native applications through conversation. It analyzes a repository to produce an application model, walks the developer through connecting a cloud environment, deploys the application on request, and can detect differences between the application deployment's desired and actual state. The developer only needs to interact with the Copilot app. | ||
|
|
||
| **Q2: What problem does GitHub Radius solve?** |
There was a problem hiding this comment.
The problem statement still reads somewhat platform-centric. Sharpening toward customer pain (what is hard today, what fails in real setups, why current approaches are insufficient).
| > | ||
| > **Internal**: Export to Bicep is not a MVP feature. See the fast-follow list in Q27. | ||
|
|
||
| **Q22: How does GitHub Radius compare to GitHub Spark?** |
There was a problem hiding this comment.
Value is mostly qualitative. Consider adding concrete success metrics (onboarding time, standardization %, drift reduction) to make impact measurable.
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Radius functional test overviewClick here to see the test run details
Test Status⌛ Building Radius and pushing container images for functional tests... |
Description
This PR contains the PRFAQ for Project Lattice—-the integration of Radius into the GitHub Copilot application for individual developers, small teams, and open-source maintainers. It contains the press release, general FAQs, and internal FAQs covering architecture, Bicep rationale, MVP scope, fast-follow features, recipe ownership, and the relationship to Kubernetes-based Radius.
The previous feature spec and UX walkthrough has been archived here.
Type of change
Contributor checklist
Please verify that the PR meets the following requirements, where applicable: