Data Handling
Data Handling
Section titled “Data Handling”Xferity is a self-hosted platform. The data handling model is determined by your deployment decisions, not by a shared cloud environment.
What Xferity processes
Section titled “What Xferity processes”Transfer file content: files being uploaded or downloaded are read from and written to paths on the host filesystem. Files in transit are not durably stored in the application layer beyond what is needed for transfer execution.
Audit records: structured JSON audit events are written to an append-only log on the host filesystem. They include file names, paths, partner context, timing, and outcomes. They do not include file content.
State records: flow run history, status, idempotency records, and job state are persisted in the configured backend (file-backed or Postgres-backed). They reference file names and outcomes, not file content.
Credentials and secrets: credentials are resolved at runtime from secret references. They are not logged in plain form. Redaction is applied before audit events are written.
Session data: in Postgres-backed deployments with OIDC or local auth, session tokens are managed in the database. They expire and are invalidated on logout.
What Xferity does not do
Section titled “What Xferity does not do”- Xferity does not upload file content to any external service
- Xferity does not send telemetry or usage data externally
- Xferity does not store file content in the state database
- Xferity does not log credentials in plain form
Your responsibilities as an operator
Section titled “Your responsibilities as an operator”Because Xferity is self-hosted, you are responsible for:
- access controls on the host filesystem, database, and network
- backup and restore of state, audit logs, and key material
- retention policies for audit logs and state records
- secure handling of key material, certificates, and secrets
- export of audit evidence for compliance or legal purposes