Manage runners · Read members
Availability
Anyone who can sign in can create a Runzivo workspace. Connect a GitHub organization you own and select the repositories you want to use.
The currently eligible runner label is rzv-ubuntu-24.04-x64-2vcpu-8gb. Creating a workspace does not add repository access: select each repository during the Runzivo Shared GitHub App connection.
Installation linking, JIT runner provisioning, and runner lifecycle transitions support the available GitHub Actions flow.
Workflow migration and coding-assistant interactions are planned and are not available for customer use. Planned features remain unavailable until implementation, authorization, and retention gates are complete.
This page describes the permissions requested during the GitHub App connection.
Requested repository permissions
- Metadata: Read. Supports GitHub App configuration, signed intake, and selected-repository authorization.
- Actions: Read and write. Supports queued-job admission now and planned job lifecycle transitions, run history, logs, and metrics.
- Contents: Read and write. Planned workflow migration needs to read and change repository content.
- Workflows: Write. Planned workflow migration needs to change workflow files.
- Pull requests: Read and write. Planned coding-assistant interactions need PR context and authorized PR updates.
- Checks: Read and write. Planned coding-assistant interactions need check context and check updates.
- Issues: Read. Planned coding-assistant interactions need issue context.
Requested organization permissions
- Self-hosted runners: Read and write. Planned runner reservation, JIT registration, binding, and removal need organization runner access.
- Members: Read. Planned membership-change handling needs minimum organization, member, team, and membership-change identifiers.
Installation scope
During installation, customers choose Only select repositories. That choice limits repository permissions to the selected repositories, and customers can add or remove repositories later in GitHub App installation settings.
Selected-repository access does not limit the separate organization permissions. Self-hosted runners and Members are organization-level scopes, requested for the purposes described above. Runzivo does not request Administration, Secrets, Variables, Environments, Packages, or Deployments permissions.
Why request planned permissions now
The requested permissions cover the available runner flow and planned workflow migration and coding-assistant capabilities. Requesting the contract at initial installation avoids an avoidable permission upgrade when a customer enables a future feature after its implementation and launch gates pass.
If requested permissions change in the future, GitHub or the customer may require a new approval. Runzivo will not assume an earlier installation approves later permission changes.
Writes and workflow control
Contents and Workflows write allow the planned migration feature to change repository content and workflow files. Pull requests and Checks write allow the planned coding assistant to update authorized pull requests and checks. These capabilities are planned, not currently available.
Actions write supports planned job-lifecycle transitions. It does not authorize Runzivo to use repository Administration operations, including runner-group repository-policy endpoints that require Administration.
Any future customer-initiated write requires authenticated customer action, tenant and selected-repository checks, and an operation-scoped installation token narrowed to the repository and permissions where GitHub supports narrowing. Repository writes are limited to a branch and pull request in the authorized repository, with no branch-protection or ruleset bypass.
A runner executes the workflow a customer selects in GitHub Actions. Workflow steps can read or modify repository data, access secrets GitHub makes available to that job, and trigger actions with the workflow's own credentials. The App permissions do not directly grant access to a live job environment, job token, or stored Actions secrets. Secrets in code, logs, artifacts, or changed workflow content remain a risk.
Customer controls and records
Customers control repository access in GitHub App installation settings by adding or removing selected repositories. Suspending or uninstalling the App stops new runner requests. A revoked or unselected repository is denied by the authorization boundary.
Raw webhook bodies are retained only in memory long enough to verify the signature and route a delivery. They are not logged or retained. Planned event acknowledgements retain nothing. Current queued-job handling persists only delivery ID, job, installation, and repository IDs, action, labels, admission decision, reason, and timestamp. It does not persist raw payloads.
The current delivery-audit table has no purge. Tenant-approved retention and deletion work is a launch blocker for onboarding and processing. Before enabling future collection, Runzivo must apply tenant-approved retention and deletion to webhook, membership, PR or issue discussion, run metadata, logs, and metrics data.
The Privacy Notice is a working draft for newsletter and Early Access information. It does not set a retention period or deletion process for GitHub App delivery audits. This page states the current GitHub App record handling and launch blocker; contact Runzivo for questions about the draft notice.