Data Handling

What WorkerRun Receives

When a workflow is triggered, WorkerRun receives a GitHub webhook payload containing event metadata: the pull request number, commit SHA, repository name, and event type. This is the same payload any GitHub App receives for subscribed events.

What WorkerRun Stores

Job-related data — webhook payloads, repository code, workflow logs, and secrets — is processed entirely in memory and discarded when the job completes. Job logs are streamed directly to GitHub (via Azure Blob) and are visible only in the GitHub Actions UI. WorkerRun does not retain logs, artifacts, or user code.

WorkerRun does store a minimal set of operational data to power the dashboard and billing:

• User account data — GitHub user ID and installation ID, stored in a Cloudflare D1 database for dashboard and billing purposes.
• Usage counts — Aggregate job counts tracked via Cloudflare Analytics Engine for quota enforcement. No job content is included.

GitHub Token Lifecycle

• WorkerRun uses a short-lived GitHub App installation token to interact with the GitHub API on behalf of the job.
• The token is scoped to the single repository that triggered the workflow.
• The token expires automatically after the job completes and is never persisted to disk or stored in any database.

Webhook Payloads

Webhook payloads are received over HTTPS and processed in memory. In V8 Isolation Mode, they are processed within the V8 isolate and discarded when the isolate is destroyed. In Container Mode, they are handled by the Durable Object and discarded when the container is destroyed. No part of the payload is written to persistent storage at any point during processing.