What Denly's servers can and cannot see: encryption and data boundaries

Your working checkout stays local; selected uploads can contain source. Optional workspace end-to-end encryption protects supported content; review its coverage and known runner/server failure paths.

The working checkout stays local. Selected uploads include repository READMEs, project docs, plan snapshots, attachments, conversations, recorded agent output (transcripts) and bounded no-Git review diffs. Full output recording is the default, including file contents and command output; workspace or project policy can select Text or Off. That diff can contain source code or secrets and is readable by anyone with task access. When workspace E2E is enabled, the diff, task text, plans, conversations, and attachments are encrypted in the browser or runner and unreadable to Denly. Without optional E2E, uploaded content is readable to the service. Skills remain plaintext for server-side validation. Known limitations: audited runner key/enrollment failures can fall back to plaintext for events and document/README uploads, and older clients are not consistently rejected at the server boundary. Browser schedule encryption and locked-key document blocking do not prove those runner/server guarantees.

Runner environment

DENLY_E2E_PASSPHRASE=your-workspace-passphrase

Passphrase loss is permanent.Denly cannot recover encrypted history. Your Git host receives pushed code and your chosen AI provider receives the context sent by its CLI under your agreements with them.