Security and data

• Isolation:
  • every job runs in its own virtual machine, created for that job and destroyed after it;
  • the VMM is sandboxed (seccomp, no privileges after setup);
  • guests cannot reach our hosts, other jobs, cloud metadata services or private networks, only the public internet;
  • shards have no network at all.
• GitHub access:
  • the app's only write permission is repository administration, used to register one runner for one job;
  • our GitHub App's private key is encrypted at rest;
  • hosts never receive it: they get a single-job runner registration.
• Hosts:
  • they make outbound connections only, authenticated with per-host tokens;
  • a host that fails its health checks (memory scans, hardware errors, replay mismatches) is taken out of service automatically.
• Recordings and artifacts:
  • they contain what your job read, including secrets;
  • they are readable only by people with access to the repository's installation, and are deleted after 30 days, or on request;
  • GITHUB_TOKEN expires when the job ends; long-lived secrets used by a job stay as sensitive in its recordings as anywhere else.
• Public repositories: pull requests from forks can run workflows on your runners, as on any self-hosted runner. Use GitHub's "require approval for fork pull requests" setting.

Report a security issue to security@hypervise.sh.