Open Source Run Configuration
Open source or public repositories typically need different CI behavior than internal repositories because contributors push from forks rather than the main repository, there is a greater risk for sensitive credential exfiltration, and contributors need to be able to see the results of their CI runs.
RWX exposes three per-repository toggles that cover these cases. They're configured under your organization's VCS integrations, on the page for the individual repository or project. The settings are only available on public repositories and are hidden on private repositories.
Enable runs on forks
When enabled, RWX will trigger runs for pull requests (GitHub) or merge requests (GitLab) opened from forks of the repository. When disabled, RWX skips events from forks.
Even when enabled, any runs triggered from forks will need to be manually started in the UI by a member of your RWX organization. This gives you a chance to review any changes to the code before that code can execute in RWX. Exercise extreme caution before manually starting any runs from forks and verify that no changes were made that could result in exfiltration of sensitive values.
Enabling runs on forks automatically disables VCS credential exposure (see below); the two are mutually exclusive.
Expose GitHub token / Expose GitLab credentials
When enabled, runs triggered for this repository receive the VCS token RWX uses to interact with the GitHub or GitLab API. Tasks that need to push commits, comment on PRs, or call the VCS API can read the credential from the run environment.
When enabled, runs triggered for this repository have access to a token that can be used to interact with the GitHub or GitLab API. Typically these credentials are unnecessary for public repositories since they can be cloned without any credentials. This setting primarily exists to preserve backwards compatibility with open-source run definitions that predated enabling runs from forks and it is hidden when "Enable runs on forks" is on.
Enable public runs
When enabled, new runs in this repository become publicly accessible — anyone with the run URL can view the run, its tasks, logs, and artifacts without signing in. Existing runs are unaffected; only runs created after the toggle is flipped become public.
The latest-run redirect used to make a badge clickable from a public README only resolves for anonymous viewers when the latest matching run is publicly accessible.
Vault access from public repositories
Vaults hold the secrets, vars, OIDC tokens, and tool caches that runs read at execution time. Because runs from public repositories can be triggered by people outside your organization, RWX treats vault access from public repos as a separate opt-in: a vault rejects public-repo access by default, even if the repository would otherwise satisfy the vault's repository and branch permissions.
Each vault has an Allow public repositories toggle on its Access Control tab. When the toggle is off (the default), runs from any public repository in the organization are denied access to the vault. When it's on, public repositories must still match the vault's normal repository and branch permissions if the vault is locked.
Allowing access to a vault for runs in a public repository is not inherently dangerous, because runs from forks must be manually approved and started by members of your RWX organization, but for defense-in-depth it is wise to only allow access to vaults that only have credentials that are essential for your RWX runs. It can also be useful to pair public repository vault access with vault approvals to give a maintainer an additional chance to review the specific run before any sensitive values are exposed to the run.