What CRACI can reach, and what it keeps

Why this question deserves a straight answer

A CI runner sees more than most tools in your stack. It checks out your source, installs your dependencies, and holds the secrets your workflows use to publish packages and deploy. When the GitHub Action tj-actions/changed-files was compromised in March 2025, CISA reported that the malicious code exposed secrets including access keys, GitHub personal access tokens, npm tokens and private RSA keys. The runner is where those secrets live while a job runs.

So before you point a workflow at CRACI, you should know exactly what it can reach. The answers are below, and the CRACI Trust Center and docs.craci.com have the details.

What the GitHub App is for

CRACI replaces the runner, not GitHub Actions. You keep your workflows, change runs-on to craci for the jobs you choose, and the runs still appear in the GitHub UI. To make that work, your organization installs the CRACI GitHub App.

When you install it, you grant the App access to either all repositories or a selected set. Only the repositories you grant access to can run workflows on CRACI.

The exact permissions the App requests are listed on the GitHub install screen, and you can review them afterwards in your organization settings. In short, the App can read your code and your Actions runs, and it manages the runners it registers for your organization.

Where your code runs

Jobs execute in isolated virtual machines. Build execution runs on European bare-metal infrastructure. Your source code is processed inside the job VM for the duration of the build.

Each job runs on one of three images: CRACI Slim, CRACI Slim ARM64, or a GitHub-compatible Ubuntu 24.04 image. Runners are Linux only.

How jobs are isolated, and what happens to a job's VM when it ends, is documented on docs.craci.com and in the Trust Center.

What CRACI stores, and for how long

CRACI processes your source code in the job VM while the build runs. What it retains is the evidence it records about each build, plus the caches your workflows save:

• Build metadata
• Package data, meaning the dependencies each job pulled
• Network traces from the job
• SBOMs
• Provenance records that link an artifact to its build
• Caches
• Audit records

A cache holds whatever your workflow puts in it, so treat cache contents the way you treat any other build output.

The default retention period is 180 days. Enterprise plans can set a custom retention period. Data deletion and encryption are covered in the Trust Center.

Hosting and data residency

CRACI is hosted in Europe and offers EU data residency, with build execution on European bare-metal infrastructure. See data residency for what data CRACI handles.

Controls you get on the build itself

A runner that sees your secrets should also let you limit where they can go. CRACI network egress policies set a default of deny or allow for each job, with 24 built-in presets for common software sources and typed custom sources for registries such as npm, PyPI, Cargo, Go proxy and OCI. You can also write explicit TLS, TCP, UDP and ICMP rules. Policies are validated before the job starts, fail closed, and reject unknown fields. Email alerts flag policy violations.

Jobs leave from a stable egress IP range, so you can allow CRACI runners through your own firewalls by address.

Access inside your organization

• Enterprise plans support SAML single sign-on, with Google Workspace as the identity provider.
• An admin audit log records administrative actions. It is available in the UI and cannot be exported yet.
• API tokens are created by admins, can be revoked at any time, and expire after 90 days.

How to keep the scope small

You do not have to give CRACI your whole organization to evaluate it.

1. Install on selected repositories. Choose "Only select repositories" when you install the App and pick one or two. You can widen or narrow the set later from your organization's Settings, under GitHub Apps, CRACI, Configure. The change takes effect immediately.
2. Move one job at a time. Only jobs with runs-on: craci run on CRACI. Everything else stays on the runner it uses today.
3. Start with a job that holds few secrets. A test or lint job shows you the SBOM and network evidence without putting publish or deploy credentials on a new runner.
4. Turn on a default-deny egress policy. Allow the package sources the job needs and nothing else.
5. Know how to leave. In GitHub, you can suspend the App, which blocks its access while keeping it installed, or uninstall it, which removes its access to your organization.

Our security posture

Our security page explains how we approach it: documented, not asserted. The Trust Center brings together the policies, controls and documentation behind the platform, and it is where you can request material for a vendor assessment.

This page makes no certification claims. For the current status of our security program and any audit work, check the Trust Center.