Cloud GitHub Gateway later
Hosted convenience comes after the trust boundary is hardened.
Cloud GitHub Gateway is the later hosted path for the same product: GitHub Connect, repository setup, Runner keys, setup snippets, My Installations, and Decisions.
It is not the primary serious-use path today. For real repositories, start with self-hosted GitHub Gateway until hosted isolation and operations are ready for broader use.
Cloud onboarding path
Hosted convenience should feel simple after the boundary is ready.
Connect GitHub installation
Select repo and branch scope
Provision Runner key
Use hosted GitHub Gateway
See guarded PRs and Decisions
Why hosted is harder
A hosted GitHub write boundary has to earn trust.
A cloud GitHub Gateway would hold sensitive control-plane responsibilities. It must handle GitHub authorization, installation ownership, provisioning isolation, and Activity visibility without becoming a blind write proxy.
- tenant isolation
- GitHub token handling
- installation and repository verification
- internal provisioning boundaries
- Activity and Decisions scoping
Design goals
Hosted should make setup easier, not weaker.
- GitHub Connect
- repository selection
- Runner key setup and one-time secret display
- sanitized Decisions dashboard
- no plaintext Runner key persistence
- no payloads, diffs, source contents, or secrets in Product UI
Clear boundary
Hosted availability is not a production promise.
The hosted path is for workflow feedback and design validation. It should not imply production readiness, enterprise readiness, automatic merges, correctness guarantees, or a claim that agents are reliable in general.