> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreload.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security model

> Coreload's security model: a fresh VM per job, what the GitHub App can do, your secrets, logs, and where jobs run.

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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.