Data Handling

Transparency about data handling is essential. Here's exactly what data StarSling accesses and how we handle it.

Data Access Summary

Data Type	Accessed	Stored	Retention
Repository metadata	Yes	Yes	Account lifetime
Workflow definitions	Yes	No	-
Source code	Yes	Temporarily	24 hours
Repository activity & context	Yes	No	-
Secrets	No	No	-
Environment variables	No	No	-
Build artifacts	No	No	-

Detailed Breakdown

Repository Metadata

What: Repository name, owner, installation ID

Why: To route webhooks and manage runner registration

Stored: Yes, in our database

Retention: Until you uninstall the GitHub App

Workflow Events

What: Webhook payloads for workflow_job events

Why: To provision runners when jobs start

Stored: No (processed in memory)

Retention: None

Workflow Definitions (Optimizations)

What: Your .github/workflows/*.yml files

When: Periodically scanned by StarSling's AI agents to identify optimization opportunities

Why: To suggest caching improvements, faster install strategies, build step optimizations, and workflow restructuring

Stored: No (processed in memory during analysis)

Retention: None

Source Code (AI Analysis)

What: Source code files in your repository

When: Accessed for AI-powered optimizations

Why: To provide context for optimization suggestions

Stored: Yes, temporarily during analysis

Retention: Deleted within 24 hours

Repository Activity & Context

What: Read-only repository signals such as deployments, issues, discussions, pages, and security events

When: Accessed alongside workflow and source analysis

Why: To give optimization suggestions broader context about your repository

Stored: No (processed in memory during analysis)

Retention: None

What We Never Access

Secrets

GitHub secrets are passed directly from GitHub to the runner. StarSling's infrastructure never sees secret values.

Environment Variables

Custom environment variables are injected by GitHub, not StarSling.

Build Artifacts

Artifacts uploaded via actions/upload-artifact go directly to GitHub's artifact storage.

Changes We Make

StarSling's AI agents propose optimizations by opening pull requests. This requires write access to code and workflows, scoped to changes the GitHub App commits on new pull request branches.

What we do:

Create a new branch and commit proposed changes
Open a pull request with an explanation for your review

What we don't do:

Push to your default branch or any existing branch
Merge or approve pull requests

See GitHub App Permissions for the full list of permissions and why each is requested.

StarSling runs every job in its own ephemeral sandbox — a single-use, hardware-isolated microVM. Each job gets a fresh microVM that is destroyed the moment the run finishes, so there's nothing for a later job, including a fork pull request, to persist on or reach.

Isolation is enforced per job at the hardware-virtualization layer, so jobs from different repositories and organizations never share a runtime. This is the same isolation model GitHub-hosted runners use.