Privacy Policy

Effective date: 2026-07-19 Who we are: dev-mux (the "Service"), operated by the dev-mux team ("we," "us").

This policy explains what we collect, what we deliberately do not collect, how long we keep it, and the strict boundary on what the operator can see.

1. Our core privacy posture — "your code never leaves your machines"

dev-mux is a control plane for your own tmux sessions and AI coding agents. The product is architected so that no customer code, repository contents, or terminal transcripts persist on our servers — this is the "zero customer code on our servers" posture, and it holds at rest (at the storage layer).

To be precise and honest about how the system actually works:

In transit / in memory: your session content transits hub RAM while a session is live — tmux panes hold terminal output in the hub's memory, and a screenshot ("shot") you capture may contain images of your code. This content transits the managed hub; we do not claim it bypasses our infrastructure entirely.
At rest: that same content is never stored to disk as customer code, repository contents, or terminal transcripts beyond the tmux server's own memory and the optional shots store described below. When the tmux session ends, the in-memory content is gone.

We choose the phrase "never stored" deliberately. Claiming content never reaches our servers at all would be false — it transits hub RAM. Saying it is "never stored" is accurate: nothing durable is written that reconstructs your code or transcripts.

2. What we store on the managed hub, and for how long

The following retention schedule is our adopted default. It is tenant-facing and binding once this policy is signed off.

2.1 Managed-hub snapshots

Daily snapshots — keep-7. Managed hubs are backed up with daily disk snapshots, and we retain the most recent 7 of them (keep-7). Older daily snapshots are deleted automatically. These snapshots exist for disaster recovery of the hub's system state.
Teardown final snapshot — keep-30. When a managed hub is torn down (e.g. after cancellation), we take one final snapshot and retain it for 30 days (keep-30), then delete it.
Export on request during the grace window + 30 days. During the account grace period plus 30 days after it, you may request a data export; we will provide the exportable data (see §3) on request within that window. After the grace-plus-30-day window closes, the final teardown snapshot is deleted and export is no longer available.

Note on snapshots vs. your code: snapshots capture the hub's disk. Per §1, your code and transcripts are never stored to that disk as durable customer content — so a snapshot does not become a hidden copy of your repository.

2.2 Shots store (screenshots) — TTL default 30 days, tenant-configurable

The optional shots store holds screenshots you explicitly capture; these images may hold code. Historically the shots store had no time-to-live (DEV_SHOTS_TTL_DAYS unset = forever). Under this policy the shots store has a default TTL of 30 days, and it is tenant-configurable — you may shorten it, lengthen it, or disable capture entirely. Shots older than the configured TTL are deleted automatically.

2.3 File-access audit log (`files-audit.log`) — retention 400 days

The files-audit.log is an append-only record of file-access metadata (which paths were listed or opened, when) used for security auditing. It does not contain file contents. Historically it was unbounded; under this policy it is retained for 400 days, matching our security-audit horizon, then rotated out.

3. What you can export

On request within the export window (§2.1) we will provide the data that is exportable — your account and tenant configuration, and any shots still within their TTL. We cannot export code or transcripts, because per §1 we never store them.

4. Operator monitoring boundary

There is a hard boundary on what the dev-mux operator can see:

The operator sees only external and system-level signals: GCP VM health (CPU, memory, disk, uptime), snapshot/backup status, egress metrics, CPU-anomaly alerts, and Cloudflare-side data.
The operator never sees, reads, or accesses your customer session content, terminal traffic, tmux buffers, or tailnet internals. We do not read your sessions to "monitor" you. The rich session dashboard is yours — you see your sessions; we see machine health.

This boundary is why our abuse guardrails (egress caps, CPU-anomaly alerts — see the AUP) can detect a pegged CPU or a bandwidth spike without ever reading what you are running.

5. What we collect off-hub

To run the business we process ordinary account data on the control plane: your email and account identifiers, plan/subscription status, billing metadata (payments are handled by our payment processor; we do not store full card numbers), and support correspondence. We use transactional email for account, billing, and support messages.

Pre-launch waitlist. Before the managed service launches, the dev-mux.com website collects early-access waitlist signups — your email plus the IP address, country, browser user-agent, and referrer sent with the request — stored in Cloudflare Workers KV and used only to send you an invite and launch updates. This is described in the site's Privacy Notice (https://dev-mux.com/privacy) and folds into this policy at launch.

6. Sub-processors

We use the following infrastructure and service providers ("sub-processors"), strictly to operate the Service; they process data on our behalf under their own terms:

Google Cloud Platform — hosts managed hubs (per-tenant VMs) and their snapshots.
Stripe — payment processing and billing (we never store full card numbers).
Cloudflare — website hosting, DNS, CDN, and the waitlist datastore (Workers KV).
Telegram — internal signup/operational notifications to the dev-mux team.
our transactional email provider — account, billing, and support email.

We keep this list current and note material changes per §8.

7. Your rights

You may request access to, correction of, or deletion of your account data by contacting [email protected]. Deletion of a tenant follows the teardown schedule in §2.1.

8. Changes

We will update the effective date and notify account holders of material changes.

9. Contact

Questions: [email protected].

Questions: [email protected]