📅 Last reviewed March 2026

Your data stays yours —
here’s exactly how.

We believe trust must be earned through transparency, not promised through marketing copy. This page documents what we collect, how we protect it, and what you can hold us to.

On this page

Our promise

Core commitments

These aren’t aspirational goals — they’re the foundational constraints we built the platform around.

🚫

No ads. No tracking. No profiling.

We do not monetise your data. We have no ad network integrations, no behavioural analytics, and no interest in what files you store. Our business model is a simple monthly subscription — you’re the customer, not the product.

🔑

You own your pod, we are only custodians.

We claim no licence over your pod’s content. We host it on your behalf. You can read, write, share, export, or delete every byte at any time — no approval required, no waiting period.

🌐

Built on an open W3C standard.

Your pod runs on the Solid protocol, ratified by the World Wide Web Consortium. It is not a proprietary format we invented. Any Solid-compatible server can host your data, which means you’re never locked in to us.

🚪

Leave at any time — and take everything.

There is no export fee, no data-hostage period, and no artificial friction on departure. We provide standard HTTP-based export and the data is stored in interoperable formats (Turtle/RDF + binary). Apps you connected follow you to your new host.

Data minimisation

What we collect

We collect the minimum required to run the service. We do not sell, rent, or share this data with third parties except as documented in the subprocessors section below.

📋

We collect

  • Email address — for account login and service notifications
  • Full name — used for your Pod WebID and billing record
  • Card last 4 digits + brand + expiry — stored for Pro plan display only; full card data is handled exclusively by Stripe
  • Pod content — the files and data you store in your pod; visible only to you and those you explicitly grant access to
  • Server-side access logs (nginx) — IP address, timestamp, HTTP method, path, status code; retained for 30 days for abuse and security purposes
🚫

We never collect

  • Ad identifiers or cross-site tracking cookies
  • Behavioural analytics or browsing history
  • Device fingerprints or canvas/font probes
  • Third-party analytics (no Google Analytics, no Segment, no Mixpanel)
  • Full payment card numbers — these never touch our servers
  • Content of your pod files for any purposes other than serving them back to you

Questions? Email support@privatedatapod.com

How we protect your data

Security practices

Defence in depth: encryption in transit and at rest, network isolation, access control at the protocol level, and automated certificate renewal.

🔒

TLS 1.2 / 1.3 in transit

All traffic between your browser and the server is encrypted with TLS. We use Let’s Encrypt certificates renewed automatically every 60 days, Mozilla’s “Modern” cipher list, HSTS with a 2-year max-age, and HTTP/2. Weak ciphers (RC4, 3DES, CBC-mode suites) are disabled.

💾

Encryption at rest

Pod data is stored on AWS EBS volumes encrypted with AES-256. The encryption key is managed by AWS KMS. This means the physical disk cannot be read without the key, even if the underlying hardware were ever accessed outside of normal operations.

🗂

Per-user pod isolation

Each pod lives in a dedicated subdirectory under the data volume ({username}.privatedatapod.com/). The CSS server enforces that every request is scoped to the authenticated user’s namespace. One user cannot access another user’s pod directory.

🛡

WAC / ACP access control

Solid’s Web Access Control (WAC) layer means you define exactly who can read or write each resource in your pod. Access is enforced server-side on every request: no client-side workaround can bypass what you’ve set. Public resources are explicitly opt-in.

🌐

Network isolation

The Solid server, the platform API, and the database are on a private Docker bridge network. The only process with an external-facing port is nginx on 80/443. Internal services are not reachable from the public internet.

Automated cert renewal

A Certbot sidecar container renews TLS certificates every 12 hours. Certificate expiry failures trigger an alert. We aim for zero certificate-expiry downtime. Wildcard certificates cover all pod subdomains under *.privatedatapod.com.

Auditable by design

Open source foundation

We didn’t build a proprietary server. We run the upstream Community Solid Server with minimal, published configuration changes — so you can verify what we run.

Built on Community Solid Server

The core of every pod is Community Solid Server (CSS) — an open-source, MIT-licenced implementation of the Solid protocol maintained by the Solid community. Our configuration additions (subdomain routing, custom templates) are minimal and available in the repository linked below.

The Solid protocol itself is a W3C specification. It is not controlled by any single company, including us. This means the rules for how your data is stored and accessed are publicly reviewed, not proprietary.

No lock-in

Data portability

Because your pod is built on an open standard, leaving is genuinely easy. Here’s what an export looks like in practice.

1

Download via standard HTTP

Every resource in your pod is accessible over plain HTTP GET. You can use any WebDAV-compatible client, curl, or a Solid data browser to download your entire pod as a directory tree. No special export tool required.

2

Standard, interoperable formats

Structured data in your pod is stored as Turtle (RDF) — a W3C standard. Binary files (images, documents) are stored verbatim. Neither format requires Private Data Pod to read.

3

Apps follow you to your new host

Solid apps connect to your pod via your WebID URL, not to us specifically. When you move your pod to another Solid provider, you update your WebID profile. Every app you’ve authorised reconnects automatically.

Third parties

Infrastructure & subprocessors

We use a minimal set of third-party services. The list below is complete — we do not use subprocessors that are not listed here.

Vendor Purpose Data accessed Region
Amazon Web Services Compute EC2 instance hosting all services; EBS volume storing pod data Pod content (encrypted at rest), server logs, all traffic us-east-1
Amazon Route 53 DNS DNS for privatedatapod.com and wildcard subdomains DNS queries only; no pod content Global
Let’s Encrypt TLS Free, automated TLS certificates via ACME protocol Domain names only; no user data or pod content Global
Stripe Billing Pro plan payment processing Name, email, and full payment card details for Pro subscribers only. Stripe never sees pod content. Global

Independent verification

Security scan results

We run regular automated security scans against the platform and publish the results here. Results are updated after each scan.

🔴
Critical 0
🟠
High 0
🟡
Medium 0
🔵
Low / Info 0
📅
Last scan March 27, 2026
🛠
Tools Custom +

Scan performed March 27, 2026. Checks: HTTP→HTTPS redirect, TLS expiry, security headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy), OIDC endpoint, scanner path blocking (12 paths), WAC enforcement, rate limiting, npm audit, testssl.sh TLS cipher analysis, trivy container CVE scan.

All checks passed

12 checks passed with no issues found across TLS, headers, scanner path blocking, WAC enforcement, rate limiting, dependency audit, and container CVE scan.

PASS

Security researchers

Responsible disclosure

How to report a vulnerability

If you discover a security issue in Private Data Pod, please disclose it responsibly. We will acknowledge your report within 2 business days and aim to resolve confirmed vulnerabilities within 30 days of disclosure.

Send your report to support@privatedatapod.com with the subject line “Security Disclosure”. Please include: steps to reproduce, affected endpoint or component, and your assessment of impact.

We do not pursue legal action against researchers who act in good faith and follow this policy. We ask that you do not publicly disclose findings until we have had a reasonable opportunity to address them.

What to include

  • 1 A clear description of the vulnerability and its potential impact
  • 2 Steps to reproduce, including any payloads or request samples (redact any real user data)
  • 3 The affected URL, endpoint, or component
  • 4 Screenshots or screen recordings if helpful
  • 5 Your suggested severity (Critical / High / Medium / Low)

We don’t operate a formal bug bounty programme at this time, but we recognise and thank researchers who help us improve security.

The legal stuff

Our policies

📜

Terms of Service

The legal agreement governing your use of Private Data Pod. Covers acceptable use, service limits, liability, and your rights as a user.

Read Terms of Service →
🔒

Privacy Policy

A full account of the data we collect, why we collect it, and your rights under applicable privacy law. Coming soon — in the meantime, this Trust Center documents our practices in full.

Coming soon

Ready to take control of your data?

Start with a free pod today. No credit card required. Move or delete your data at any time.

Get your free pod →