Trust & Privacy

Your work lives where you choose to run it.

Warpdrive can run Apps and AI on your own computer. It can also use hosted Warpdrive services, a remote connection, or an outside AI provider. Those choices change where data goes. This page tells you the difference without pretending every setup is fully local.

Implementation review: August 23, 2026.

Local-first is not the same as local-only.

A local Instance keeps its Workspace and running App on the machine that hosts it. Conversation storage, sign-in, remote access, telemetry, and AI requests may still use other systems. Read the path for each one below.

How it works

You choose each path your data takes

Files, prompts, credentials, and remote traffic enter Warpdrive in different ways.

01 Choose a Workspace

Your files enter here

Warpdrive uses the folder you select. A local Instance reads and writes it on that host.

02 Start an Instance

Work gets its own runtime

The Instance gets its own state, agent home, credentials, and container when Docker is used.

03 Choose the AI

Prompts follow that choice

A local model handles inference on the host. An outside provider receives the context sent to it.

04 Connect remotely

Only when you enable it

A paired remote session sends commands, responses, and terminal bytes through the relay.

FilesSelected Workspace
PromptsConversation composer
CredentialsInstance sign-in or provider settings
Remote trafficPaired remote connection
Storage

Where your work is stored

Simple answers come first. Open technical details only when you want the exact boundary.

Apps

Where are Apps stored?

A source-based App is stored in the Workspace used by its Instance. If that Instance is on your computer, the App is on your computer. A hosted App is different: Warpdrive stores its catalog record and opens the publisher's hosted URL.

Technical details

The local runtime places managed App worktrees below /ws/.warpdrive/apps inside the Instance. /ws is the selected host Workspace mounted into the runtime. Hosted package entries do not require a source checkout.

Conversations

Where are Conversations stored?

Conversation history follows the control plane you use. The current desktop Gateway app uses a hosted control plane, so its Conversation history is not guaranteed to stay only on the desktop. A fully self-hosted control plane keeps that database with its operator.

Technical details

Current control-plane code stores full message text and reported AI response text in a protected settings payload. The service can use SQLite or PostgreSQL. The database location therefore depends on the deployment, not on the screen used to send a message.

Source code

Where is source code stored?

Source files live in the selected Workspace. A local Instance reads and writes that host folder. Copies or excerpts can leave when you publish, push to a source host, use a hosted Instance, or let an outside AI provider read code for a task.

Technical details

Docker-backed Instances bind-mount the chosen host Workspace read-write at /ws. Marketplace source installs clone a pinned revision into that Workspace. Publishing, Git remotes, support uploads, remote terminal output, and provider context are separate transfers and can send source off the machine.

Credentials

Where are AI keys and logins stored?

There is more than one credential path. Codex and Claude Code sign-in state is created inside each running Instance and persists in that Instance's saved agent home. Custom provider API keys saved through the account UI are stored as protected credential data by Warpdrive Identity and delegated to an Instance when used.

Technical details
  • Agent homes are separate per Instance under the runtime host's Warpdrive state directory.
  • Warpdrive does not copy the host user's Codex or Claude credential into a new Instance.
  • Hosted Identity protects saved provider tokens with ASP.NET Data Protection before database storage.
  • Desktop account and relay secrets still use local protected files. Keychain migration is not complete.
Warpdrive infrastructure

What passes through Warpdrive, and what it stores

Using a local runtime does not remove every hosted service from the path.

In transit

What data can pass through Warpdrive?

Account and sign-in requests, catalog and billing requests, control-plane commands, Conversation content, and orchestration state can use Warpdrive services. If remote access is on, command bodies, responses, and terminal bytes pass through the hosted relay.

Technical details

The relay forwards authenticated HTTP request and response frames and can stream a terminal as encoded byte frames. Product telemetry carries feature use, resource IDs, timing, prompt length, and outcome metadata; the telemetry emitter does not accept a raw-prompt field. That does not mean other product paths never carry prompt text.

At rest

What does Warpdrive store?

Hosted services can store account and security records, saved provider credentials, Conversation and orchestration state, App and marketplace metadata, billing records, relay records, and telemetry. Your machine stores Workspaces, runtime state and logs, per-Instance agent state, and local connection settings.

Technical details

Relay state includes paired-device records, credential and pairing-code hashes, queued or completed command records, and security events. Retention varies by data type and deployment. See the policy links below for current hosted retention terms.

Quick map

Common data paths

DataLocal pathHosted or outside path
App sourceSelected WorkspaceSource host, hosted Instance, or publisher when chosen
Conversation textSelf-hosted control-plane databaseHosted control plane in the current Gateway app
Agent login statePer-Instance agent homeProvider account systems during sign-in and use
Custom API keyNot the default account-UI pathProtected in Warpdrive Identity, then delegated for use
Remote terminalRuns on the Instance hostTerminal bytes cross the hosted relay while connected
Local-model inferenceModel runtime on your machineNo third-party model API call; other Warpdrive paths may remain hosted
Access boundaries

Remote access, isolation, and people

Remote connections

How are remote connections secured?

The local worker opens an outbound connection; it does not need a public inbound port. Pairing uses a short-lived code, and the relay uses a device credential. An HTTPS Gateway produces a WSS connection.

Technical details

The connector sends the device credential in WebSocket subprotocol data and retries outbound connections. Local relay credentials are encrypted with AES-256-GCM using an owner-only key file beside the config. This protects the connection and local credential; it is not an end-to-end encryption claim.

Instances

How are agent Instances isolated?

Docker-backed Instances use separate containers, state folders, agent homes, networks, and credentials. The Workspace you choose is still mounted read-write so the agent can do its job. Native or no-Docker workspaces do not provide the same container boundary.

Technical details

Hosted-tenancy code blocks the Docker socket, applies workspace allowlists and runtime hardening, and tests cross-Instance routes. The selected Workspace remains available to the Instance because the agent needs it to perform the work you requested.

Warpdrive staff

Can Warpdrive employees access Apps or Conversations?

Data that stays only on a self-hosted machine is controlled by that machine's operator. Data stored by hosted Warpdrive services is within systems operated by Warpdrive and may be available to authorized staff for support, security, or legal needs.

AI choice

What changes with local and third-party AI

Local AI

Can prompts and data stay entirely local?

A local model keeps model inference on your machine and removes the third-party model API call. That choice alone does not prove the whole Conversation stays local, because the current Gateway app can still use a hosted control plane and relay.

An entirely local design requires a self-hosted control plane, local runtime, local model, and no hosted relay, sync, telemetry, source host, or outside integration.

Technical details

Local AI setup downloads a runtime and model, then points OpenCode-compatible agents at the local server. After setup, the inference request needs no AI-provider API key. Sign-in, updates, marketplace, billing, and any separately enabled network feature remain distinct.

Third-party AI

What changes when I use an outside provider?

The provider receives the prompt and whatever context the agent sends. That can include source snippets, filenames, tool output, and Conversation history needed for the task. The provider's security, retention, training, and account policies then apply.

Technical details

Warpdrive shows a data-sharing consent step before provider dispatch in supported Conversation flows. That consent does not change the provider's own processing terms. Review the provider account and model endpoint before sending sensitive work.