Security

Documentation Index

Fetch the complete documentation index at: https://docs.pipedata.io/llms.txt

Use this file to discover all available pages before exploring further.

​

Transport

All traffic uses modern TLS, both between you and Pipedata and between Pipedata and your egress endpoints. Weaker protocols are rejected at the edge.

​

Authentication

pd login uses a device-code flow and stores an API key in ~/.pd/config.json (mode 0600). All pd commands and direct HTTP ingress requests authenticate with this key as Authorization: Bearer <key>. Each key is bound to a single workspace; requests that do not match are rejected before the data is read.

​

Encryption at rest

Records are encrypted per workspace before being written to disk, and only decrypted into memory when they need to be read, transformed, or delivered. Encryption keys are stored separately from the data they protect, so access to a data file alone does not expose its contents, even with administrative access to the underlying disk. Compromising one workspace’s data does not affect any other. This application-level encryption sits on top of full-disk encryption at the infrastructure layer.

​

Infrastructure

Pipedata runs on servers with full-disk encryption and restricted administrative access. Production systems are isolated from development and internal tooling.

​

Tenant isolation

Pipes, API keys, and encryption keys are all scoped to a workspace. Cross-workspace access is not possible through the data API: the ingress server checks workspace ownership of the API key against the workspace ID in the request path on every call.

​

Data residency

Data is currently stored and processed in the EU (EU central region). Additional regions are planned.

​

Data retention and deletion

Records are retained for as long as the pipe that holds them exists. When you delete a pipe, its data is removed. Deleting a workspace removes all its pipes and their data.

​

Audit trail

Configuration changes (creating, editing, or deleting pipes, API keys, and workspaces) are recorded so administrators can review who changed what and when, whether the change came from the CLI or the dashboard.

​

Incident response

Security incidents follow a defined playbook: detect, contain, investigate, and fix. If an incident affects your data, we notify the workspace owners without undue delay and share what happened, what data was involved, and what we are doing about it.

​

Subprocessors

Pipedata uses the following subprocessor to operate the service: