Starwisp runs in your GitHub organization and your Cloudflare account. This page says where your keys live, what Starwisp can and cannot do, what we never see, and why the GitHub App has the permissions it has.
Where your keys live #
| Secret | Lives in | Who can read it back |
|---|---|---|
| Vendor keys (Anthropic, Expo, Supabase, Cloudflare, Resend, Apple, Google, Twilio) | GitHub Actions secrets on <org>/factory | Nobody. GitHub never shows a secret value again after it is saved. The Vault is write-only by design. |
| GitHub App private key and webhook secret | GitHub Actions secrets on <org>/factory | Nobody |
Console sign-in settings (AUTH_SECRET, AUTH_URL, AUTH_GITHUB_ID, AUTH_GITHUB_SECRET, FACTORY_ORG, FACTORY_REPO) | Your Cloudflare Worker's secrets | Only you, in your own Cloudflare account |
| Idea Studio's Anthropic key | Your Cloudflare Worker's secret ANTHROPIC_API_KEY | Only you |
| Your license key | Your computer's installer state file (~/.starwisp/install.json: a file only your user can read, in a folder only your user can open) | You |
The console's Worker holds only its sign-in settings (and the Idea Studio key). Your vendor keys are not in the Worker.
How the installer handles secrets #
The GitHub App's private key, webhook secret and client secret exist in the installer's memory only. They go straight into gh secret set and wrangler secret put over standard input. They are never on a command line, never in the state file, and never written to disk, not even a temporary file.
What Starwisp can and cannot do #
It can, using the keys you give it and inside your accounts:
- create repositories, branches and pull requests in your organization;
- run workflows on your GitHub Actions quota;
- call vendor APIs (Anthropic, Supabase, Expo, Cloudflare, Resend, Twilio) with your keys, to build and deploy your apps;
- upload builds to TestFlight and Play internal testing with your store keys, when you reach that stage.
It cannot, and does not:
- submit your app to the App Store or Play Store for you. Submission is a button you tap. Starwisp automates your own uploads.
- hold or see any of your keys. Support never asks for a key.
- run anything hosted by us. There is no Starwisp cloud. There is no revenue share.
- use a Claude subscription. API keys only.
Two kinds of job #
- Agent jobs (where Claude writes code) never hold privileged secrets such as the GitHub App key.
- Privileged jobs (creating repos, writing secrets) never run an AI model.
Issue text, idea attachments, logs and pull request comments are treated as data, never as instructions to the agents.
What we never see #
- Your vendor keys, GitHub App private key, or Cloudflare token.
- Your app's code, ideas or prompts. They go from your accounts to Anthropic under your own agreement with Anthropic.
- Your Worker, repos or runs.
What our servers do receive #
Only these:
| Call | Sends | When |
|---|---|---|
| Download | your signed license key, to get a release | when you install, or run the Update (see updates) |
| Release feed | nothing about you: a plain request for a public list of versions, dates and changelogs, with no license, account or repository name | when you open Home or Settings, for the "Update available" banner. Settings → Updates → Check for updates turns it off. |
Nothing runs in the background or phones home beyond that. Our server logs keep an order id and a version for support.
The GitHub App and why it has each permission #
The installer creates a private GitHub App named Starwisp <your-org>. Its webhook is off. Sign-in to the console uses the App's own user sign-in. GitHub issues those sign-in tokens for 8 hours with a refresh token; the console renews them on its own, keeps both in its encrypted, http-only session cookie, and never sends them to the browser's JavaScript.
| Permission | Level | Why |
|---|---|---|
| Administration (repository) | write | Create each app's repository and apply its quality-gate rules |
| Contents | write | Push code and commit settings |
| Issues | write | File the idea as an issue and set run labels |
| Pull requests | write | Open pull requests, including the Update PR |
| Actions | write | See run status, and start workflows from the console (Vault Test, Resume, Update, Submit, the desk's Build and Design buttons) |
| Secrets | write | Store keys the build needs in each app's repo |
| Variables (Actions) | write | Store APP_ID and similar |
| Workflows | write | Update PRs and new apps include workflow files |
| Organization members | read | The console checks that you belong to the organization |
| Metadata | read | Always granted by GitHub |
Jobs request only the subset they need for their task when they ask GitHub for a short-lived token. When you use the console, it acts with your own sign-in, which can do only what both you and the App may do.
Installed before release 0.1.1? Your App has Actions: read, so every console button that starts a workflow (the Vault's Test first of all) stops with "the Starwisp GitHub App needs the permission Actions: Read and write". To fix it: open https://github.com/organizations/<org>/settings/apps, choose your Starwisp App → Permissions & events → Repository permissions → Actions → Read and write, and click Save changes. GitHub then asks an organization owner to accept the new permission: open https://github.com/organizations/<org>/settings/installations, choose the App, and click Review request → Accept new permissions.
You can read the App's permissions any time at https://github.com/organizations/<org>/settings/apps. Remove the App to cut off Starwisp's access to GitHub. Deleting a vendor key at the vendor cuts off access to that vendor.
Where one token passes through #
Keys you paste on Settings → Vault travel from your browser to your own console Worker, which encrypts them to GitHub's public key and writes them as Actions secrets. They stay in memory for that request, are not logged, and are not stored in the Worker. The Setup page and the diagnostics file never contain a key value.
Why the GitHub App can change workflow files #
Your Starwisp GitHub App holds the Workflows: write permission. It exists for one reason: a new release usually changes files under .github/workflows, and GitHub refuses to push those without it. The app uses it only in the update job, which pushes a branch in your factory repo and opens a pull request. You review and merge that pull request yourself; nothing changes in your workflows until you do. The update job's token is scoped to your factory repository only and lasts about an hour.
Your part #
- Create keys only for Starwisp, with the narrowest scopes each vendor page lists, and note their expiry dates.
- Set an Anthropic spend limit (see costs).
- Keep at least one other owner on your GitHub organization.
- Never paste a key into a support message or an issue. Use support instead.
Plain-text version of this page: /docs/security.md. This page is copied from the product's own docs, so it matches the release you install.
Next: Updates