Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.crewship.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Telemetry

Crewship sends anonymous crash reports to help the maintainer diagnose bugs in the v0.1 beta. This page covers what is sent, how to opt out, and how to redirect crash data to your own Sentry project.
This guide is about crash reporting (the crewship telemetry command). For distributed-tracing setup (OpenTelemetry spans into a collector) see Tracing. Different package, different concern — same English word.

​
Default for v0.1 beta: enabled

The first time you run crewship start, telemetry is enabled automatically and a consent row is written to the local database. There is no first-run prompt — non-interactive deployments (Docker, systemd, CI) would otherwise end up silently telemetry-less, and a solo maintainer needs the crash signal during beta. The default-on stance applies to the v0.1 beta only. It will revert to opt-in for v1.0 GA. If you’d rather opt out immediately, run the command below before or after the first crewship start. Opt-out is sticky — once you’ve said no, the beta default never flips it back on.

​
Opting out

crewship telemetry off
Output: 
Telemetry disabled. No crash reports will be sent.
The setting is stored in app_settings.telemetry_opt_in in the local SQLite database and survives binary upgrades. To opt back in: 
crewship telemetry on

​
Checking current state

crewship telemetry status
Sample output when enabled: 
Telemetry: ENABLED
  install_id: 7c4a9f1e2b...
  endpoint:   o12345.ingest.sentry.io (vendor default (compiled in))
  to disable: crewship telemetry off
  • install_id — anonymous random identifier (32 hex chars) generated on first opt-in, stable across opt-out/opt-in cycles. The backend uses it only to group crashes by install; it carries no PII.
  • endpoint — the host portion of the resolved Sentry DSN, so you can see where events route without the full secret-shaped URL ending up in terminal scrollback.

​
Routing to your own Sentry

If you self-host or have a regulated environment that can’t share crash data with the vendor, point Crewship at your own Sentry project with the CREWSHIP_SENTRY_DSN env var: 
CREWSHIP_SENTRY_DSN=https://<key>@<org>.ingest.sentry.io/<project> crewship start
Resolution order (most specific wins):
  1. CREWSHIP_SENTRY_DSN environment variable
  2. The vendor DSN compiled into the release binary
  3. Empty — telemetry stays off regardless of consent
crewship telemetry status will show CREWSHIP_SENTRY_DSN env override as the source when your value is in use. Local development builds ship with an empty compiled-in DSN, so they are off by default unless you provide one.

​
What is sent

When telemetry is enabled:
  • Go stack traces and error messages (subject to scrubbing — see below)
  • Crewship version, commit SHA, OS, and architecture
  • The anonymous install ID (random 32-hex)
  • A Sentry “environment” tag derived from the version (beta, production)

​
What is never sent

The client-side BeforeSend hook in internal/crashreport/sentry_adapter.go strips the following before the event leaves the process:
  • Workspace, user, or credential data
  • HTTP request bodies
  • Authorization, Cookie, Set-Cookie, X-API-Key, X-Auth-Token, X-CSRF-Token, X-Amz-Security-Token, Proxy-Authorization, and X-Crewship-Internal-Token headers
  • Query-string keys whose name contains token, secret, password, auth, session, code, or key
  • Environment variables
  • The machine hostname — Sentry’s ServerName field is overridden with the anonymous install ID
  • The Go module list, runtime/device/culture contexts that sentry-go normally attaches
The pinning test TestScrubEvent_DropsLeakyContexts in internal/crashreport/crashreport_test.go enforces this list — adding a new context to the Sentry event requires updating the scrub hook or the test fails.

​
Server-side scrubbing as a defense in depth

The client scrub catches everything in structured fields. It cannot reliably catch free-form strings we generate, e.g. fmt.Errorf("auth failed for %s", userEmail). The maintainer’s Sentry project has server-side regex scrubbing rules enabled (@email-pattern, @password-pattern, @creditcard-pattern, bearer-token and API-key regexes) to mask anything that slips through. If you’ve routed Crewship to your own Sentry project via CREWSHIP_SENTRY_DSN, configure the same rules under Project Settings → Security & Privacy → Data Scrubbing. The full rule list is documented in RELEASING.md.

​
Verifying nothing leaks

The cheapest end-to-end check is to opt in temporarily, raise a test error in your own Crewship instance, and inspect the event in the Sentry UI:
  1. crewship telemetry on
  2. Trigger a known-safe error (e.g. crewship retry <run-with-nonexistent-id>)
  3. Open the resulting Sentry event
  4. Confirm headers/query/env contexts are absent and ServerName matches your install ID
If anything looks wrong, file an issue (security label) at github.com/crewship-ai/crewship/issues and opt out (crewship telemetry off) while it’s investigated.
  • Tracing (OpenTelemetry) — distributed tracing pipeline, different package, different opt-in surface.
  • Threat model — broader security posture.
  • PRIVACY.md in the repo (PR #441) — first-pass privacy policy: data controller (Unify Technology s.r.o.), GDPR rights, supervisory authority (ÚOOÚ), and the two real outbound surfaces (crewship version --check + the optional background update notifier, both GitHub-Releases-API only).
  • NOTICE
    • THIRD-PARTY-NOTICES.md — Apache-2.0 §4.4 attribution + auto-generated dependency NOTICE aggregate (Next.js, Prisma, Docker Go SDK, cosign).
  • RELEASING.md in the repo — maintainer-side Sentry project setup.