06
Infrastructure dependencies: current state and roadmap.
honest about
the gaps
Paramant's application infrastructure is fully EU-based and EU-owned:
- Application servers: Hetzner (Nuremberg, Germany & Helsinki, Finland)
- Email delivery: Resend (EU data processing agreement)
- SIEM/logging: Wazuh on dedicated EU infrastructure
Two dependencies at the DNS and CDN layer currently sit outside this boundary:
DNS and CDN: Cloudflare (current, being replaced)
paramant.app currently uses Cloudflare for DNS hosting and static asset delivery. Cloudflare is a US company incorporated in Delaware, subject to US jurisdiction including the CLOUD Act and FISA 702.
The practical impact is bounded by architecture: all file content is encrypted client-side with ML-KEM-768 before any network transit. Cloudflare terminates TLS but receives only ciphertext, so it cannot read file contents, encryption keys, or recipient identities. What is theoretically observable at the Cloudflare edge: source IP addresses, request timing, request volume, and HTTP headers (not body content).
For most threat models this is acceptable. For high-sensitivity use cases (legal, government, healthcare under strict NEN 7510 interpretation) where even metadata exposure is a concern, this is a gap we are closing.
Migration to Bunny.net (Q2 2026)
Paramant is migrating DNS and CDN infrastructure to Bunny.net, a Slovenian company (EU jurisdiction, GDPR-native, not subject to CLOUD Act) with 119 edge PoPs and comparable latency to Cloudflare.
The migration is phased to avoid downtime:
- Phase 1 (Q2 early): DNS-only migration from Cloudflare to Bunny DNS, with a nameserver change at the registrar and zero downtime if TTLs are managed correctly
- Phase 2 (Q2 mid): Static asset CDN via Bunny Pull Zone, with parallel paths during transition
- Phase 3 (Q2 late): Full reverse proxy via Bunny with WAF, replacing Cloudflare DDoS protection
Full migration plan including rollback procedures is documented in the repository (docs/migration-bunny.md).
why we document this
Claiming full EU sovereignty while running DNS on a US company is a contradiction. This section exists because transparency about current limitations is more useful than aspirational claims. The gap is bounded, the mitigation is architectural, and the migration is planned. That is an honest position.
This section was added following community feedback (GitHub Issue #20, raised by Stensel8).