Browse docs

Security & data handling

How environment variables, code, and conversations are encrypted, where they live, and who can access them.

Three questions come up in almost every security review. Here are the straight answers.

Are env variables, code, and chats encrypted in transit?

Yes. All traffic between your browser and the app is TLS 1.2/1.3 — HTTP requests and live WebSocket connections alike. Plain HTTP is redirected to HTTPS and we send HSTS, so browsers won't downgrade.

Connections to our database and to third parties (GitHub, model providers) are encrypted too.

At rest?

Yes. The database and file storage are encrypted at the disk level, with encrypted backups.

On top of that, credentials get a second layer: your environment variables, API keys, and git tokens are individually encrypted with AES-256-GCM inside the database, using keys held separately from the data. They're ciphertext even to someone reading the raw database rows. Production won't start without those keys configured, so it can't quietly fall back to storing anything in plaintext.

Your source code stays in your own GitHub repository — we don't keep a durable copy. Working copies exist only in temporary, per-session sandboxes that are destroyed afterwards.

Can darting.dev access our variables, code, or chats?

Between customers: no. Isolation is enforced in the platform itself, and a request for another tenant's data returns "not found" rather than "forbidden" — so it can't even be used to confirm something exists. Each of these controls has an automated test that fails if it's ever removed.

By our own staff: a small number of platform administrators can access customer data for support and incident response — as is true of any hosted service. That access is restricted, and every instance is written to an audit log. Encrypted secret values require the separate encryption keys as well, which are not available through normal application access.

One thing worth being upfront about

Environment variables are made available inside your project's sandbox, and any member of your team with access to that project can read them there. That's intended — it's how your app gets its configuration — but it means project secrets are shared across your team, not private per user. Scope write-capable tokens accordingly, and use private threads for work that touches something sensitive.