Building LogPulse Without a US Kill Switch

In March 2025, a US executive order threatened to ban European companies from using American cloud services unless certain data-sharing conditions were met. The order was walked back within days, but the message was clear: if your product runs on American infrastructure, your business exists at the pleasure of American trade policy. We started building LogPulse six months later, and that episode shaped every architectural decision we made.

This post is not about politics. It is about engineering. Specifically, it is about how we designed a production-grade log management platform where every core component is either European, open-source, or replaceable within a week. Not as a theoretical exercise -- as a concrete, tested migration path.

The Principle: Core vs. Peripheral

We draw a hard line between core and peripheral components. Core components are the ones your customers interact with directly: the database that stores their logs, the query engine that searches them, the API that ingests them, the pipeline engine that transforms them. If a core component disappears overnight, your product is dead.

Peripheral components support the product but do not define it: the CDN that serves the marketing site, the email service that sends password reset links, the OAuth provider that offers social login, the AI model that generates query suggestions. If a peripheral component disappears, you have a bad week -- but your customers can still ship logs, search them, and set up alerts.

Our rule is simple: core components must be either European or open-source with no single-vendor dependency. Peripheral components can be American, but each one must have a documented European alternative and a migration plan that takes no more than five working days.

The Core Stack: No American Dependencies

Let us walk through the core stack and explain why each choice was made.

ClickHouse — Log Storage

ClickHouse is the foundation of LogPulse. It stores every log entry, executes every search query, and powers every dashboard. We wrote an entire blog post about why we chose it over Elasticsearch, but the sovereignty angle deserves its own explanation.

ClickHouse is open-source under the Apache 2.0 license. It was originally developed at Yandex in Russia and is now maintained by ClickHouse Inc. The source code is publicly available and can be self-hosted on any infrastructure. We run ClickHouse Cloud on GCP europe-west4 (Netherlands) -- our log data physically resides in a European data center and never leaves the EU.

If ClickHouse Inc. ceased to exist tomorrow, we could self-host the same software on Hetzner bare-metal servers in Falkenstein, Germany. The @clickhouse/client library we use is open-source. The schema, the queries, the materialized columns -- everything is portable. There is no proprietary API, no vendor lock-in, no license key that can be revoked.

PostgreSQL — Metadata & Configuration

All non-log data -- user accounts, team configurations, API keys, alert rules, pipeline definitions -- lives in PostgreSQL. Like ClickHouse, PostgreSQL is open-source with no single-vendor dependency. We use Drizzle ORM for migrations and type-safe queries, but Drizzle generates standard SQL. If we needed to switch ORMs, the database schema would remain unchanged.

PostgreSQL runs on any cloud provider, any VPS, any bare-metal server. Moving it from a US-hosted provider to a European one is a pg_dump and pg_restore away.

Redis — Job Queue

Our log ingestion pipeline uses BullMQ backed by Redis for job queuing. Both are open-source. Redis runs anywhere. The queue configuration is fewer than 50 lines of code. Migrating to a European-hosted Redis instance means changing a connection string.

Fastify — API Framework

The LogPulse API runs on Fastify, an open-source Node.js web framework primarily maintained by an Italian and European core team. It is not owned by a US company, not governed by a US foundation, and not dependent on any proprietary service. Our entire API -- ingestion, querying, authentication, pipeline management -- runs on Fastify with standard open-source plugins for CORS, rate limiting, WebSocket support, and security headers.

React Flow — Pipeline Editor

The visual ETL pipeline editor uses React Flow (now @xyflow/react), built and maintained by a team in Germany. The library is open-source under the MIT license. It is one of the most critical UI components in the product -- users build their entire data transformation logic on it -- and it has zero American corporate dependency.

LPQL — Our Own Query Language

We built LPQL (LogPulse Query Language) from scratch. The tokenizer, parser, AST, and SQL compiler all live in our own packages/lpql-parser package. There is no external dependency for query processing. LPQL compiles directly to ClickHouse SQL, and since ClickHouse is open-source, the entire query pipeline from user input to database result is free of proprietary dependencies.

This is a deliberate contrast to products that depend on Elasticsearch Query DSL or Splunk SPL. If those vendors change their query interface, their customers have no recourse. LPQL is ours, and it goes wherever we go.

The Peripheral Stack: American, but Replaceable

We use several American services for peripheral functionality. Here is each one, why we chose it, and what the migration path looks like.

OpenAI → Mistral AI

The AI Query Generator uses OpenAI gpt-4.1-mini to translate natural language into LPQL queries. This is a convenience feature -- it makes LogPulse easier to use, but it is not required. Every query the AI generates can be written manually by the user.

The migration path is straightforward. Mistral AI is a French company with models that match or exceed GPT-4.1-mini performance for structured output tasks. Our AI integration is a single file (ai-query-generator.ts) with a clean interface: natural language in, LPQL out. Swapping the model provider means changing the API endpoint and adapting the prompt format. We estimate two days of work, including testing.

Alternatively, we could self-host an open-source model like Mistral or Llama using vLLM on European GPU infrastructure. This eliminates the external dependency entirely.

Cloudflare → Hetzner or BunnyCDN

Cloudflare serves our marketing website (logpulse.io) and runs a small community API on Workers. The marketing site is a static React app -- it can be served from any CDN or web server. The community API is fewer than 200 lines of code and could run on any edge platform or a simple Express server.

BunnyCDN is a Slovenian company with European-owned infrastructure. Hetzner, based in Germany, offers cloud servers and object storage at competitive prices. Moving the static site to either takes an afternoon. The community API could move to a Hetzner VPS or a Fly.io instance in Amsterdam.

Railway → Hetzner Cloud or OVH

Our API server and background worker currently run on Railway, a US-based platform. Railway is convenient for deployment, but our services are standard Node.js applications with no Railway-specific code. They use environment variables for configuration and Docker for containerization.

Migrating to Hetzner Cloud (Germany) or OVH (France) means deploying the same Docker containers to European infrastructure. We use no Railway-specific APIs, no proprietary build hooks, no platform-locked features. The deployment script would change; the application code would not.

Microsoft Azure Email → Brevo

Password reset emails and alert notifications currently route through Microsoft Graph API via Azure AD. This is arguably the easiest component to replace. Brevo (formerly Sendinblue) is a French email platform with full EU data residency. Our email service is a single package (packages/email) with a clean send() interface. Swapping the transport layer from Microsoft Graph to Brevo SMTP means changing one file.

Google & GitHub OAuth → Self-Hosted

We offer Google and GitHub as social login options. These are convenience features -- users can always sign up with email and password. If we needed to remove US OAuth providers, we could replace them with European alternatives or deploy a self-hosted Keycloak instance. Our authentication library (Better Auth) supports arbitrary OAuth providers through a plugin interface.

Better Auth itself is open-source and runs entirely within our API process. There is no external auth service to depend on -- the library handles session management, password hashing, and token generation locally.

The Migration Playbook

We maintain an internal document that describes, for every American dependency, the exact steps to migrate to a European alternative. Here is the summary:

OpenAI to Mistral AI: swap API client and prompt format in a single file. Estimated effort: 2 days. Log data exposure: none (only natural language questions and schema metadata are sent to the model, never log content).

Cloudflare to BunnyCDN or Hetzner: redeploy static assets and update DNS. Estimated effort: 1 day. Community API to Hetzner VPS: containerize and deploy. Estimated effort: 1 day.

Railway to Hetzner Cloud: deploy existing Docker containers to Hetzner. Migrate PostgreSQL via pg_dump. Point Redis to Hetzner-hosted instance. Estimated effort: 3 days.

Azure Email to Brevo: change email transport in packages/email. Estimated effort: half a day.

Google and GitHub OAuth to Keycloak: deploy Keycloak on European infrastructure, update OAuth configuration. Estimated effort: 3 days.

Total migration from fully American peripheral stack to fully European: approximately 10 working days. During migration, core functionality (log ingestion, search, alerts, pipelines) continues to operate without interruption because none of those systems depend on American services.

What About React, TypeScript, and Node.js?

Yes, React is maintained by Meta. TypeScript is maintained by Microsoft. Node.js is stewarded by the OpenJS Foundation. These are all open-source projects licensed under permissive terms (MIT and Apache 2.0). They cannot be revoked, restricted, or turned off. The source code is mirrored on thousands of servers worldwide. No trade policy can prevent you from running npm install.

There is a meaningful difference between depending on a US SaaS service (where access can be terminated with a configuration change) and using open-source software created by a US company (where the code is permanently in the public domain). We care about the former. The latter is a non-issue.

Why This Matters

European companies processing log data have regulatory obligations under GDPR. Many operate in sectors -- healthcare, finance, government -- where data sovereignty is not a preference but a legal requirement. Even outside regulated industries, the past two years have demonstrated that geopolitical risk is operational risk.

We built LogPulse so that a European company can adopt it knowing that their logs are stored in Europe, processed by open-source software, and served by infrastructure that can be relocated to fully European providers within two weeks. Not as a future roadmap item -- as a tested, documented capability.

Your log data is too important to exist at the mercy of a foreign trade policy. We designed LogPulse so it never has to.