Home Self-Hosting & Sovereignty Deploying Konversio for EU sovereignty

Deploying Konversio for EU sovereignty

Last updated on Jun 05, 2026

Deploying Konversio for EU sovereignty

Self-hosting is not the same as sovereignty. You can run Konversio on your own server and still have legal exposure if that server, its DNS provider, its email relay, or its AI backend is subject to US jurisdiction. This article explains what genuine sovereignty looks like in practice and gives you a concrete checklist.

What sovereignty actually means

The question is not only "where is the data stored?" but "who can compel access to it?"

The US CLOUD Act (2018) allows US authorities to compel US-headquartered companies to hand over data stored anywhere in the world, including data held by their European subsidiaries and European-region cloud instances. This creates a conflict with GDPR's prohibition on transferring personal data outside the EU without adequate safeguards.

Running on AWS eu-west-1 or Azure West Europe does not resolve this. The parent companies are US entities. For a full explanation of this conflict and its legal status, see the CLOUD Act / GDPR conflict page on konversio.org.

Konversio was built to make it possible to close this gap entirely.

Architecture checklist

Work through this list to assess your deployment.

1. Run on EU-owned infrastructure

Choose a cloud or bare-metal provider headquartered in the EU with no US parent.

Tested and recommended:

  • Scaleway (France) — tested by the Konversio team; good Docker support, EU object storage, GPU instances for model inference
  • Nebius (EU-incorporated, operates GPU clusters in Europe) — tested for Pilot with Llama/Qwen inference
  • Hetzner (Germany) — cost-effective VPS and dedicated servers, no GPU but solid for app + database
  • OVHcloud (France) — large provider, good network, bare metal options

Avoid: AWS, Azure, GCP, DigitalOcean (US-owned), Linode/Akamai.

2. Use an EU-controlled AI provider for Pilot

The default Pilot configuration is provider-agnostic. Sovereign options:

  • Mistral API (French company, EU-hosted inference) — PILOT_AI_PROVIDER_URL=https://api.mistral.ai/v1
  • Scaleway AI — hosts Mistral and other models on Scaleway infrastructure
  • Self-hosted Ollama — run Gemma 4, Qwen 2.5, or Mistral locally on your own server; no external API call at all; set PILOT_AI_PROVIDER_URL=http://localhost:11434/v1 and leave PILOT_AI_API_KEY blank

3. Keep email within the EU

SMTP is a common oversight. Use an EU-headquartered transactional email provider:

  • Brevo (France, formerly Sendinblue)
  • Mailpace (UK/EU, carbon-neutral)
  • Your own Postfix/Exim — maximum control, more operational overhead

Avoid Mailgun, SendGrid, Postmark — all US-owned.

4. Disable third-party telemetry

Set DISABLE_TELEMETRY=true in your .env. This prevents any analytics pings from leaving your instance. Verify with a network monitor on first boot that no outbound calls go to unexpected hosts.

5. Control your own encryption keys

For database encryption at rest, use your provider's disk encryption or LUKS on bare metal — with keys you hold. If using object storage for attachments, use server-side encryption with customer-managed keys (CMK/BYOK) where your provider supports it.

Scaleway Object Storage and OVH both support SSE with managed keys.

What this buys you

A deployment following this checklist runs with no dependency on any US-jurisdiction service. Customer conversation data — messages, contact details, attachments, AI inference inputs — stays within EU legal borders at every step. This is what "European strategic autonomy" means in operational terms, not just a marketing claim.