Data Handling ​

Before adopting Bumpkit you need to know what code and data it sees and keeps; this page explains it and the controls you have, for security, privacy and legal reviewers.

This page describes what leaves your machine when you use Bumpkit, what Bumpkit stores, and the controls you have over it.

What you send to Bumpkit ​

Requests are authenticated with your API key in the x-api-key header. The API rejects release check requests larger than 10 MB.

What is sent to the AI provider ​

Bumpkit's own checks decide the release verdict. The AI provider only adds explanations, and its findings are marked inference. For a release check it receives:

• The first line of recent commit messages
• The title, severity and file of each finding
• A limited excerpt of the diff

When a release is very large, Bumpkit sends less, or skips the AI step, and the summary says it covers only part of the release. Blocking decisions never use AI: the verdict and every gate failure come from Bumpkit's own checks.

Checks sent with fast: true skip the AI step; bumpkit gate --hotfix (or running on a hotfix branch) sends them that way. A raw POST /v1/gate with hotfix: true and no fast still uses it. Changelog generation sends commit messages. Plain-English rules (Beta) send the rule text, and release docs send the engineering notes generated for the release.

What Bumpkit stores ​

By default, Bumpkit keeps the results it produces, not your source tree. It never stores the diff you send. Per check it stores:

Bumpkit also stores what you create: codebase memories, incidents, deployments, finding feedback, gate overrides, policy rules, changelog entries and the audit log.

Credentials and secrets ​

Secrets encryption at rest ​

Bumpkit encrypts these secrets with AES-256-GCM before storing them:

• Slack and Discord webhook URLs, the outbound webhook URL, the Linear API key and the PostHog API key
• Slack bot tokens
• Incident source and deploy source secrets
• Change management credentials (Jira, ServiceNow, Teams, Vanta, Drata) and Notion and Confluence tokens
• OIDC client secrets, when single sign-on (Beta) is configured
• Audit streaming destination secrets
• GitLab, Bitbucket and Azure DevOps gate connection secrets and access tokens
• The workspace's evidence signing key

Bumpkit never writes these secrets in plain text, and encryption keys support rotation.

Sign-in protection ​

Password sign-in is rate-limited per account and per network, and repeated failures pause sign-in for that email address for a while. Sign-up needs a confirmed email, password reset links work once and expire in 30 minutes, a new sign-in email has to be confirmed from its own mailbox, and the dashboard refuses cross-site form posts. See Sign-in security.

What Bumpkit sends to other services ​

Delete a workspace ​

On the dashboard, the workspace owner opens Settings → Delete workspace, types delete and confirms. This permanently deletes the workspace and everything in it, including its memberships, API keys, checks and integrations. Team members keep their Bumpkit accounts and their other workspaces. From the CLI, run bumpkit workspace delete. It can't be undone.

Zero retention ​

Beta, early access. A workspace without access gets 403 FEATURE_EARLY_ACCESS and a link to request it. Flag: zero_retention.

The Data tab on the dashboard's Settings page (/settings?tab=data) shows exactly what is stored for the workspace, how many records of each kind, where it's stored and what the AI provider receives. Any member can view it. The owner (and, with roles on, an admin) can change the settings and export the data; only the owner can delete it.

Retention modes ​

What each mode keeps:

Switching to a stricter mode also scrubs what is already stored to match, right away. Switching back to standard doesn't restore removed data.

What the AI provider receives ​

In findings_only and ephemeral workspaces, release checks send no code to the AI provider, unless Bumpkit's agreement with that provider includes zero data retention. When it does, checks use AI explanations as usual.

The Data handling page shows the provider, its endpoint, whether it's marked zero retention, the inference region and whether code is sent.

Retention windows ​

Set how long request logs and findings are kept, from 1 to 3650 days, or 0 to keep them until you delete them.

Bumpkit applies the windows automatically.

API ​

curl -X PATCH https://bumpkit.dev/v1/data \
  -H "x-api-key: $BUMPKIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"data_retention": "findings_only", "findings_days": 90}'

GET /v1/data and PATCH /v1/data return:

{
  "data_retention": "findings_only",
  "label": "Findings only",
  "description": "Findings are kept with their file, lines and a short hashed fingerprint. ...",
  "request_log_days": 0,
  "findings_days": 90,
  "llm": {
    "provider": "anthropic",
    "endpoint": "https://api.anthropic.com",
    "zero_retention": false,
    "inference_geo": "us",
    "code_sent": false,
    "note": "..."
  },
  "stored": [
    {"name": "Release checks", "count": 412, "contains": "Refs, commit SHA, verdict, version bump, counts and agents", "code": false}
  ]
}

Every change is recorded in the audit log (data.retention, data.windows). From the CLI, bumpkit data view shows them and bumpkit data set changes them (--retention, --request-log-days, --findings-days, --region; --yes confirms changes that remove stored content).

Export workspace data ​

Beta, early access. A workspace without access gets 403 FEATURE_EARLY_ACCESS and a link to request it. Flag: zero_retention.

The owner (or, with roles on, an admin) downloads everything stored for the workspace as one JSON file, from Data handling → Download export, bumpkit data export --output FILE or GET /v1/data/export:

curl -o bumpkit-workspace-export.json https://bumpkit.dev/v1/data/export \
  -H "x-api-key: $BUMPKIT_API_KEY"

The file has "format": "bumpkit-workspace-export/1", exported_at, exported_by and one section for each kind of data: the workspace and its members, API keys, release checks with their findings, changed files, gate decisions, overrides, votes and release docs, codebase memories, incidents and their sources, deployments and their reviews, release health and error counts, finding feedback, policy rules, request logs, releases and the audit log.

Secrets and key hashes are left out: API keys appear only as prefix, label, revoked flag and dates, and incident sources omit their secrets. Each export is recorded in the audit log as data.export. A workspace can export 5 times per hour; beyond that the API returns 429 RATE_LIMIT_EXCEEDED with Retry-After: 3600.

Delete workspace data ​

Beta, early access. A workspace without access gets 403 FEATURE_EARLY_ACCESS and a link to request it. Flag: zero_retention.

The owner can permanently delete a workspace's data while keeping the workspace, from Data handling → Delete data, signed in to the dashboard, confirming with the exact workspace name. bumpkit data delete and the API refuse a key and say where to do it. A denial on a commit keeps holding that commit, with the person's name and email removed.

The response counts the records removed for each kind of data.

Deletion runs immediately and all at once. It removes release checks (with their findings, changed files, gate decisions and release docs), codebase memories, incidents, request logs, changelog entries, finding feedback, deployments, gate overrides, error fingerprints and counts, policy rules, gate votes, Slack approval messages, Slack pull request messages and deployment reviews. Members, API keys, settings, integrations and the audit log stay. The deletion and the counts are recorded in the audit log as data.delete.

To remove the workspace itself, delete the workspace.