# 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.