Coreload: GitHub Actions runners Security model

Your jobs

• Each job runs in a fresh VM that never serves a second job or a second customer. Its disk and memory are deleted with it when the job ends.
• Coreload doesn't store your secrets. A secret your workflow passes to a job is visible inside that job's VM while it runs, so pass short-lived, least-privilege credentials.

What the GitHub App can do

The Coreload CI App asks for exactly these permissions:

• Organization self-hosted runners: write
• Actions (the repositories you choose): read
• Metadata (the repositories you choose): read

• The self-hosted runners permission covers your whole organization. Coreload uses it only for its own runner group and the single-use runners it registers there, and never touches your other runners or groups.
• The App has no access to your repository contents, issues, pull requests or secret values. Its Actions access could download workflow logs and artifacts of the repositories you chose; Coreload uses it only to read job status and labels, and never downloads logs or artifacts.

Service logs, and where jobs run

• Operational records (job and runner ids, timings, organization and repository names, error codes) go to our service logs, which are kept for 30 days.
• Usage records for billing, and your organization's setup record, are kept longer than service logs.
• Jobs run on bare-metal machines, each job in a fresh VM.