# We know who touches your data > This continues our [Proudly made in EU](/en/hrde-vytvoreno-v-eu) principle: we choose key suppliers by jurisdiction, operational control and a strict need for third parties. [Canonical HTML](https://dreamind.cz/en/seznam-zpracovatelu) ## EU-first is not a slogan. It is a concrete supplier list. Below are suppliers we use for infrastructure, emailing, analytics, form protection and payments. A specific project may use only part of this list. ### 8 — suppliers in the core stack Not every project uses all of them. Scope follows the actual data flows. ### 6 — EU suppliers Key infrastructure and operational services stay primarily under European jurisdiction. ### 1 — self-hosted non-EU exception We use Umami as software while analytics data remains on our own servers. The goal is not to have the longest processor list. The goal is to know each supplier's role, where infrastructure runs and whether the service should be involved at all. ## A supplier must make sense technically and legally For every supplier we look at operational role, jurisdiction, data location and our ability to keep critical layers under control. ### European jurisdiction by default Servers, databases, storage, DNS, emailing and analytics are handled primarily through European partners. ### Fewer third parties We add services only when they have a clear purpose. Global platforms are not our automatic default. ### Self-hosted where it adds control When self-hosting makes sense, we run the tool on our infrastructure and separate software vendor from data custody. ## Who we use and why This list describes our common operating baseline. For client projects we confirm the exact use, scope and contractual setup. ### Hetzner - **Jurisdiction:** Germany + Finland; German supplier, primary operations in Germany, redundancy in Finland. - **Role:** Main infrastructure supplier. - **Control note:** Primary layer for projects where we want operations, data and redundancy to remain in the EU. **What we use the supplier for** - Servers and compute - Databases - Storage - DNS - CDN - Proxy layer ### Scaleway - **Jurisdiction:** France; French infrastructure supplier. - **Role:** Secondary infrastructure supplier. - **Control note:** Used where a French EU alternative or a secondary layer outside primary hosting makes sense. **What we use the supplier for** - Databases - Storage - Occasional server capacity - Backup infrastructure scenarios ### Wedos - **Jurisdiction:** Czechia; Czech domain and hosting supplier. - **Role:** Domains, DNS and smaller PHP application servers. - **Control note:** Useful for Czech domains, simpler website operations and cases where a local supplier is appropriate. **What we use the supplier for** - Domain registration and management - DNS - Servers for PHP applications ### Lettermint - **Jurisdiction:** Netherlands; Dutch partner for email infrastructure. - **Role:** Main emailing partner. - **Control note:** Used for operational communication where deliverability and a European partner matter. **What we use the supplier for** - Transactional emails - Newsletters - Deliverability and sender reputation ### Mosparo - **Jurisdiction:** Switzerland; Swiss supplier of a self-hosted form protection tool. - **Role:** Self-hosted spam protection. - **Control note:** We deploy it self-hosted, so form protection runs in an environment we manage. **What we use the supplier for** - Form protection - Automated spam reduction - Alternative to invasive CAPTCHA tools ### Umami - **Jurisdiction:** USA, self-hosted in the EU; US analytics software supplier; analytics data remains on our servers. - **Role:** Self-hosted analytics platform. - **Control note:** The exception is the software supplier outside the EU, not default storage of analytics data outside our infrastructure. **What we use the supplier for** - Product and website analytics - Custom event tracking - Performance insight without marketing pixels ### Plausible - **Jurisdiction:** Estonia; Estonian privacy-first analytics supplier. - **Role:** Analytics for projects that do not need self-hosting. - **Control note:** Chosen where hosted analytics with an EU-only approach is enough and a dedicated instance is unnecessary. **What we use the supplier for** - Website traffic - Light conversion measurement - Privacy-first reporting ### Comgate - **Jurisdiction:** Czechia; Czech payment gateway with an EU-only approach. - **Role:** Payment gateway. - **Control note:** Based on supplied information, Comgate runs its own infrastructure and does not use AWS or Google Cloud. **What we use the supplier for** - Online payments - Payment workflow - E-commerce and customer portal integrations ## We distinguish company, software and data location Not every entry means the same kind of processing. What matters is where data actually runs and who can access it. ### Umami is a US software supplier We use it self-hosted. That means analytics data is kept on our infrastructure and Umami is not the default external data store. ### The list changes by project An e-commerce project may need a payment gateway, while a presentation website may not. SaaS can have stricter requirements for infrastructure, backups and auditability. Want to build on the EU-first approach? Read [Proudly made in EU](/en/hrde-vytvoreno-v-eu) or review your current stack with us. ## Questions about the processor list ### Does every project use every supplier listed here? No. The list shows our common supplier stack. For each project we confirm only the services that are actually involved. ### Does self-hosted always mean more control? Usually yes, when infrastructure, access, backups and monitoring are designed correctly. We treat self-hosting as an operational decision, not a label. ### Why is Umami listed if the company is from the US? Because we use it as self-hosted software. The key point is that analytics data stays on our infrastructure, and we describe this exception explicitly. ### Can the processor list be adapted for sensitive projects? Yes. For sensitive projects we can narrow the supplier list, choose self-hosted variants and design stricter control over data flows. ## We will review your stack and data flows. - Identify which suppliers actually touch data - Suggest EU-first alternatives - Recommend a practical migration or adjustment plan [Book a consultation](/en/kontakt)