The short answer
Your data lives in Frankfurt, Germany, in the European Union, and stays there at rest. The application infrastructure (database, object storage, compute, backups) is all in DigitalOcean's FRA1 region. There is one transient exception: the AI extraction step sends document content to Anthropic's Claude API in the US for a few seconds of processing, then returns the structured result, which is stored in Frankfurt.
This article walks through the storage architecture and the rationale for each design choice. For the encryption layer specifically, see how our encryption works, in plain English. For the full sub-processor list with transfer mechanisms, see our sub-processors and the canonical /subprocessors page.
The storage stack in detail
Primary database — Frankfurt
A managed PostgreSQL 16 cluster in DigitalOcean's FRA1 region, with point-in-time-recovery enabled and daily snapshots. The database holds:
- Account metadata (email, hashed password, 2FA TOTP secret, account-level settings)
- Company records (name, country, base currency, VAT ID)
- Document metadata (upload date, source, content type, extraction results)
- Extracted invoice and receipt fields
- Bank-transaction records and matching state
- Trading partners (your vendor + customer registry)
- Audit-log entries (every meaningful action with attribution)
Sensitive fields (TOTP secrets, OAuth refresh tokens, IBANs, tax IDs) get an additional field-level encryption layer on top of the database's at-rest encryption.
Object storage — Frankfurt
DigitalOcean Spaces (S3-compatible) in the same FRA1 region. Holds:
- The original PDFs, JPGs, PNGs, HEICs you upload or that arrive by email
- Generated exports (JSON files for year-end exports, advisor exports)
- Any derived artefacts (low-res previews, thumbnails)
Server-side AES-256 encryption on the Spaces side, plus our application-layer envelope encryption (see below) so we can crypto-shred per-account.
Compute — Frankfurt
Application servers run on DigitalOcean Kubernetes (DOKS) in FRA1. Stateless: a pod can be killed and replaced without data loss, because all state is in the database or Spaces. The Celery workers that handle OCR, email polling, bank matching, and exports all run in the same cluster.
Backups — Frankfurt
Database backups are automated by DigitalOcean Managed Postgres, stored in FRA1, encrypted at rest with AES-256. Retention follows the managed product's default (multi-day point-in-time recovery + weekly snapshots). Backups never leave the EU.
Object storage (Spaces) is versioned within the same region; there's no off-region replication.
The one EU exit — AI extraction
When you upload a document, the backend sends the document content to Anthropic's Claude API for AI extraction (vendor, amounts, VAT, dates, line items). This call is to Anthropic's infrastructure in the United States. The flow:
- Your document is decrypted in-memory in our Frankfurt cluster.
- The content is sent to
api.anthropic.comover TLS. - Anthropic processes it, returns the structured fields, typically within 1–5 seconds.
- Our backend writes the structured result back into the Frankfurt database.
- The decrypted in-memory copy is dropped from our side.
What goes to Anthropic:
- The document content itself (the PDF text, OCR'd image text, or image bytes if no extractable text).
What does not go:
- Your account metadata
- Your bank-transaction history
- Your tax advisor's identity or any other related-party data
- Your email, your name, anything outside the document being extracted
The legal basis for the transfer
- Transfer mechanism: EU-US Data Privacy Framework (DPF, July 2023) plus Standard Contractual Clauses (SCCs) as the backup mechanism. Anthropic is on the DPF participants list.
- Anthropic's retention default: up to 30 days for safety monitoring on the commercial API. This is Anthropic's standard policy, not specific to us.
- Zero-retention addendum: in active negotiation with Anthropic. Once signed, document content is dropped immediately at Anthropic's side with no monitoring retention. We will publish the executed addendum on our /security page when it's signed. Until then, we don't claim it.
If your threat model requires no US transfer at all today, the AI extraction path is the gap to be aware of. We're not aware of an EU-only foundation-model offering at comparable quality, which is why the transfer happens. For everything else (storage, compute, backups, sub-processors), we're fully EU-only.
CLOUD Act exposure
DigitalOcean is a US-incorporated company. The US CLOUD Act (2018) allows US courts to compel US-based companies to produce data they hold, including data stored on EU infrastructure if the company can technically access it.
Our mitigation: application-layer envelope encryption with per-account keys. The keys to decrypt your data live in our application's key-management layer, not in DigitalOcean's infrastructure as plaintext. If DigitalOcean's staff were compelled to hand over your data, they could retrieve ciphertext only — not anything readable.
This is not a complete defence; sophisticated adversaries with sustained access could in theory exfiltrate ciphertext and then attack the application layer separately. It's the strongest commercially-available mitigation against the most common form of CLOUD-Act compulsion (a court order asking the hosting provider for the raw data of named EU users).
The full encryption design is at how our encryption works and the technical breakdown is on /security.
What we encrypt where
| Layer | Mechanism |
|---|---|
| Document files in object storage | DigitalOcean SSE-AES-256 + application-layer envelope encryption with per-account keys |
| Database rows | Managed Postgres encryption at rest (AES-256) |
| Sensitive fields (TOTP secrets, OAuth tokens, IBANs, tax IDs) | Additional field-level encryption with separate key material |
| In transit, browser ↔ our app | TLS 1.2+ (TLS 1.3 negotiated where supported) |
| In transit, our app ↔ DigitalOcean / Anthropic / Stripe / Resend | TLS 1.2+ on every connection |
| 2FA secrets | Encrypted in the database, never sent over the wire after pairing |
| Passwords | Argon2id hashes only — we never store plaintext |
| Backups | Encrypted at rest by Managed Postgres |
For the envelope-encryption explanation (per-account keys, the MEK/UEK/DEK terminology), see how our encryption works.
Sub-processors at a glance
The full list with locations, transfer mechanisms, and DPA references lives at /subprocessors. The summary:
- DigitalOcean — infrastructure (Frankfurt, US-incorporated; DPF+SCCs + envelope encryption mitigation)
- Anthropic — AI extraction (US, DPF+SCCs; zero-retention addendum in negotiation)
- Stripe — payments (US, DPF+SCCs)
- Resend — transactional email + inbound webhook (US/EU)
- Sentry — error monitoring with PII scrubbing (US, DPF+SCCs)
- Cloudflare — CDN / DDoS / WAF (Global, DPF+SCCs)
We notify all users 14 days in advance of any new sub-processor — by in-app banner, on the Subprocessors page, and (for material additions) by email.
What happens to the storage when you delete
Account deletion is GDPR Article 17 ("right to erasure"). After a 30-day grace period (during which you can restore the account), the encryption key tied to your account is destroyed. Every document, every database row, every backup containing your data becomes mathematically unreadable — for us, our staff, our backups, forever.
This is "crypto-shredding": deletion enforced by key destruction rather than best-effort row deletion. It satisfies Article 17 cryptographically. See delete your account and export your data for the deletion walk-through.
Audit-log entries required by law (financial trail under §147 AO / §257 HGB, 10-year retention) survive crypto-shredding because they're stored with a separate key set; they're pseudonymised (your email is anonymised but the financial-trail record stays so we can answer a tax-authority audit years later).
Troubleshooting / common questions
I'm a German user — am I "data offshored" because DigitalOcean is American? No. Your data sits physically in Frankfurt. Application-layer envelope encryption means DigitalOcean's staff cannot read it even if compelled by a US court order; they'd retrieve ciphertext only. Full design on /security.
What if I need contractual data-residency for the AI step? Tell us. Once Anthropic's commercial zero-retention contract is signed, we'll publish that on the /security page. Until then we won't claim it — we'd rather be honest about the current state.
Can I see my own backup? Backups are operational (for disaster recovery), not user-accessible. To get your own data, use export your records or your GDPR right to data portability via [email protected].
Is there a way to opt out of the AI extraction transfer? Not currently. The AI extraction is the core value-add of the product; without it, TaxItEasy is a storage system, not an automation tool. Once the Anthropic zero-retention addendum is signed, the transfer remains but with no monitoring retention at Anthropic's side.
What if your hosting provider has an outage? Multi-AZ within FRA1 for the managed Postgres + Spaces; the cluster spans availability zones. Region-wide outage would mean downtime (typically minutes to hours, based on DigitalOcean's published SLA history). Data is not at risk because backups are within-region. There's no off-region disaster-recovery setup today.
My country has stricter data-localisation laws than the EU average. Tell us via [email protected] with your jurisdiction and the specific requirement. We'll be straightforward about whether we can meet it; we won't add region-specific accommodations as marketing without contractual backing.
Related
- How our encryption works, in plain English — the per-account key + crypto-shredding story
- Our sub-processors at a glance — full list with transfer mechanisms
- Your GDPR rights as a user — access, rectification, erasure, portability
- Delete your account and export your data — the deletion + key-destruction walk-through
- Enable 2FA — first thing you should do