What Deck stores.
Usage totals and crash reports from the app.
Feedback you choose to send.
Deck uses small usage snapshots to understand which agents and features people use, whether its own updates reach people, and where to focus development. They describe participating install-days, not total installations, individual journeys or user retention.
Which version are you running?
Deck 1.1.0 and later send usage analytics automatically and have no in-app
opt-out.
No account is required. Releases up to 1.2.0 send every field below except
updates; later releases send all of them.
The public 1.0.0 release and older Tauri builds do not send these analytics. Earlier development builds that show a “Share usage stats” setting follow that setting. This notice describes the analytics-enabled client and its receiving service; publishing it does not change an installed build.
The complete payload
Each request contains only the following fields. The service rejects additional fields.
- schemaVersion
- The payload format version, currently 1.
- dailyId · day
- A random identifier generated for each local calendar day, plus that date. It lets repeated snapshots replace the same daily record. There is no permanent installation identifier in the payload.
- version · platform · arch
- The Deck version, macOS or Windows, and ARM64 or x64 architecture.
- agents
- Daily launch counts for Claude, Codex, OpenCode, Antigravity, Gemini and Cursor Agent. All custom agents share a single “custom” bucket; their names and commands are never sent.
- surfaces
- Daily open counts for the browser, Explorer and usage dashboard.
- maxTabs · maxPanes
- The highest number of simultaneous tabs and panes that day.
- restoredSessions
- Whether any session was restored that day, as a yes-or-no value.
- updates
- Daily counts of Deck's own update steps: checks that got an answer, checks that failed, answers that offered an update, downloads that finished or failed, and installs started. Counts only — no error messages, update versions or times.
Never in this payload: code, prompts, replies, terminal output, file names or paths, repository or branch names, browser URLs, agent commands, account names, hostnames, locale, time zone, or individual action timestamps.
The receiving service adds a first-received timestamp solely to enforce retention. It does not read or store your IP address, user agent or location as analytics fields.
Small, cumulative snapshots
The client sends a snapshot after startup, roughly every 15 minutes when counters change, a six-hour heartbeat, and a best-effort final snapshot when it quits or hands an update to the installer. Later snapshots replace the same day's counters instead of adding them again.
Deck keeps up to seven daily buffers locally to retry failed delivery. The service accepts dates from the preceding 30 UTC calendar days through the following day, allowing for local time zones. Older snapshots are discarded rather than reintroduced after cleanup.
Requests travel over HTTPS to api.deck.spacevibe.dev/v1/ping. No public
usage statistics or usage-data export endpoint is provided. These unauthenticated counts
are internal product feedback, not verified adoption figures.
A short life for daily records
Raw daily records are scheduled for deletion from the live database within 35 days of first receipt. Cleanup starts at day 34 to leave room for the daily job; a failed job can delay deletion and requires operator attention.
Before deletion, the service retains coarse totals grouped by day, app version, platform and architecture. These totals contain no daily identifier and may be kept longer for internal analysis. Aggregation and deletion happen in one database transaction.
Cloudflare D1 also maintains recovery history through Time Travel. Depending on the account plan, deleted data can remain recoverable for up to 30 additional days (7 days on the free plan). This recovery history is separate from the live database retention schedule.
Where the request goes
SpaceVibe operates the receiving service on Cloudflare Workers and D1. Worker request logging, invocation logging and tracing are disabled for this service.
Cloudflare necessarily handles network metadata, including IP addresses, while delivering and protecting requests. Disabling application logging does not remove that infrastructure processing. See Cloudflare's privacy policy for its practices.
The website hosting this notice is served by Vercel and has its own network delivery processing. See Vercel's privacy policy.
Feedback you choose to send
You can send feedback without signing in. We do not ask for your name or email, and we do not send notification emails for feedback.
Your title, description, feedback type, draft identifier and submission dates are stored in Supabase Postgres. Optional screenshots are stored in a private Supabase Storage bucket. We confirm receipt only after the report and all its screenshots have been saved. An interrupted upload may leave a private partial report until you retry or the maintainer removes it.
Complete reports and screenshots become public immediately after submission. Everyone can read the report and view its screenshots without signing in. Remove passwords, private code, personal details and image metadata you do not want to share before uploading. We store the uploaded image bytes without automatically removing embedded metadata.
The maintainer manages reports in Supabase and can hide or remove them. Hiding a report stops future public access to its images but cannot recall copies already downloaded. Hiding does not erase the stored report or its files.
The page saves text, category and a random draft identifier in your browser's local storage so you can retry. Selected images stay in page memory and must be selected again after a reload. Clearing site data removes the local text draft, but does not erase a submitted report.
Feedback is separate from app usage analytics and has no automatic expiry. The maintainer can remove a report and its images on request. Infrastructure backups, where enabled, have a separate lifecycle from live records. See Supabase's privacy policy. Cloudflare processes feedback requests and Vercel hosts the website; the service does not store request IP addresses or user agents.
Crash and error reports
Packaged Electron builds automatically send crash and error reports to Sentry, with no in-app opt-out. This includes uncaught exceptions and rejections, linked errors, and abnormal renderer or helper-process exits. Tauri builds, browser previews and unpackaged runs do not send these reports.
Reports can contain error messages, stack traces, source lines from Deck's app bundle,
and Deck, Electron, Chromium, Node, platform and architecture details. File paths can
appear in error messages and stack traces. Deck replaces occurrences of the current
user's home-directory path with ~; other path text may remain.
Deck disables breadcrumbs, local-variable capture, native crash dumps, console and request-event capture, and Sentry's default personally identifying data. Reports are sent to Sentry for processing; the usage-analytics retention period above does not describe crash-report retention.
Questions or corrections?
Contact the maintainer through the SpaceVibe Deck issue tracker. Please do not include private code, credentials or other sensitive information in a public issue.
Material changes will receive a new dated notice. This October 8, 2026 notice introduces anonymous feedback and screenshots in Supabase. The previous September 18, 2026 notice described Google-authenticated feedback, moderation, durable storage and email updates. The September 12, 2026 notice and September 7, 2026 notice remain available.