Your Code Is Not Safe on US Servers

Why I Dug Into This

I am building an AI-powered coding system. Proprietary architecture. Original code. Trade secrets that represent years of work. When it came time to put it online, I had a simple question: where do I host this so nobody can take it without my knowledge?

That question led me down a path I did not expect. I learned that if I hosted on AWS, Google Cloud, or any US provider, the US government could compel that provider to hand over my source code, and a gag order would prevent the provider from ever telling me it happened. My intellectual property could be copied, examined, or shared, and I would never know.

That is not a hypothetical. That is the law. And it does not just apply to source code. It applies to your customers’ data, your users’ files, your business communications, everything on that server.

The Problem

If your server is hosted by a US company, or your traffic passes through one, the United States government can access your data without telling you. Without telling the company. Without a public court hearing. Without meaningful oversight.

This is not conspiracy. It is law. FISA courts issue secret orders. National Security Letters come with gag provisions that legally prohibit the recipient from disclosing that a request was made. The CLOUD Act compels US companies to hand over data stored anywhere in the world. Bulk collection programs operated for years before the public learned they existed.

If you run a business, your customers trust you with their data. If you are a developer, your code is your livelihood. If you run a community, your members trust you with theirs. The infrastructure decisions you make, where you host, what CDN you use, what network your traffic crosses, are not just technical decisions. They are decisions about who can access your data and under what legal standard.

This article breaks down the three layers where your data is exposed, what each layer means legally, and how to make infrastructure choices that protect your intellectual property and the people who trust you with their information.

Jurisdiction Is Not a Feature. It Is the Foundation.

Most people choose a hosting provider based on price, uptime, and dashboard quality. Jurisdiction is an afterthought, if it is a thought at all. That is a mistake.

The country your server lives in determines what law governs access to your data. Not your terms of service. Not your privacy policy. Not your encryption settings. The law of the land where the hardware sits, and the law that governs the company that operates it, is what determines whether your data can be taken without your knowledge or consent.

If you have read our article on why no US tech company can protect your data, you know what US law looks like. Here is what the alternative looks like.

What German Law Actually Looks Like

German law works fundamentally differently from US law when it comes to government access to data.

• No gag orders. Under German law, secret data requests like US National Security Letters are not legally possible. If German authorities request data from your hosting provider, the company can tell you. In the United States, a gag order legally prohibits the company from ever disclosing that your data was handed over. You never find out.
• Judicial authorization required. Only German judges can authorize access to traffic data, and only for serious criminal acts: murder, child pornography, robbery, bomb threats, blackmail. This is defined in §100a of the German Code of Criminal Procedure (StPO). It is not a blanket order. There is no equivalent of a FISA court issuing bulk collection warrants in secret.
• Proportionality. Every data request must be proportional to the crime being investigated. Collecting everyone’s data to find one suspect does not meet that standard under German law. The principle of proportionality is not a guideline. It is a legal requirement.
• Constitutional protection. In 2008, Germany’s Federal Constitutional Court created a constitutional right guaranteeing the integrity and confidentiality of IT systems. Online searches by authorities require a search warrant. This right does not exist in US law.
• No data retention for email. There is no German law requiring email or hosting providers to store your data for government access. Providers are not required to keep records so authorities can request them later.

Compare that to the United States. FISA court orders are secret. National Security Letters come with gag orders. The company that hands over your data is legally forbidden from telling you it happened. Bulk collection programs operated for years before the public learned they existed. The system is designed so you never know.

German law is designed so you can know. That is not a small difference. That is a structural difference in how a legal system treats its citizens’ data.

The Three Layers of Exposure

Hosting your server in Germany is not the whole picture. Your data touches multiple layers between a visitor’s browser and your server. Each layer has its own jurisdiction and its own risks. Understanding this is the difference between actual privacy and the illusion of it.

Layer 1: Your Server

This is what you control. A server in a German data center sits on German hardware, under German law. You hold the SSH keys. You choose what runs on it. TLS terminates here if you are not using a CDN. This is the strongest position you can be in.

If your server is hosted by a US company, whether AWS, DigitalOcean, Google Cloud, or Linode, it does not matter where the data center is located. The CLOUD Act compels US companies to produce data regardless of where it is stored. A US company with a Frankfurt data center is still a US company.

The company matters as much as the location. You need both: a non-US company and a non-US data center.

This is the layer that matters most for source code and intellectual property. Your hosting provider has full access to your server’s filesystem: your source code, your database, your configuration files, your SSH keys. Everything. If the US government compels a US hosting provider under the CLOUD Act, they get all of it.

Layer 2: The CDN or Proxy

If you put a CDN in front of your server, the CDN terminates TLS, not your server. The CDN decrypts the visitor’s traffic at its edge, reads the content, caches it, applies security rules, then opens a separate encrypted connection to your origin. Every CDN works this way. They have to. You cannot cache or optimize content you cannot read.

But a CDN is a proxy, not a host. It only sees HTTP traffic passing through it: requests from visitors and responses from your server. It does not have access to your server’s filesystem. It cannot see your source code, your database, or your configuration files. It does not have SSH access. It is a front door, not a landlord.

This means the CDN layer is primarily a risk for user data in transit: form submissions, API responses, login sessions, personal information your users send and receive. That data passes through the CDN in plaintext. The question is: who sees it, and what law governs them?

• A US CDN: your users’ data in transit is visible to a US corporation subject to FISA, the CLOUD Act, and National Security Letters with gag orders. They cannot see your source code, but they can see everything your users send and receive.
• An EU CDN: your users’ data in transit is visible to an EU company subject to EU law. GDPR applies. The CLOUD Act does not. Same visibility into traffic, different legal jurisdiction governing it.

CDN providers operate edge servers around the world, including in the United States. When an American visitor hits a Bunny.net edge server in New York, the traffic is handled on US hardware. But the hardware is owned and operated by a Slovenian company. The encryption keys are held by that company. The CLOUD Act does not apply to them. If US authorities seize the physical hardware, they get encrypted data they cannot read. To get the keys, they would need to go through EU legal channels, not a secret US court order.

That is the difference. With a US CDN, a US court compels a US company under US law. With an EU provider, even one running edge servers on US soil, the keys and the company are outside US jurisdiction. The hardware location matters less than who controls the encryption.

No CDN provides true end-to-end encryption from visitor to origin. That is not what CDNs do. The edge server decrypts traffic in memory to cache and serve it. But the company that controls those servers and holds those keys determines which legal system governs access. If you want TLS to terminate only at your server and nowhere else, do not use a CDN.

What Each Layer Can Actually See

• Hosting provider: everything. Source code, database, config files, SSH keys, all data at rest. This is where IP protection matters most.
• CDN: HTTP traffic only. User requests, server responses, form data, API calls. Cannot see source code, database, or files on disk. This is where user data protection matters most.
• Backbone: encrypted traffic and metadata only. Cannot read content. Knows who talked to whom and when.

Layer 3: The Network Backbone

Between the visitor and your server (or CDN edge), traffic crosses the internet backbone. Undersea cables. Fiber lines. Routers operated by companies like Cogent, Lumen, and AT&T. Many of these are US companies.

With TLS, the content of your traffic is encrypted in transit. Backbone providers cannot read it. But they can see the metadata: source IP, destination IP, packet sizes, timing, duration. They know who is talking to whom, when, and how much data is moving. They just cannot read what is being said.

This is not theoretical. The NSA’s upstream collection programs, revealed in the Snowden disclosures, operated by tapping fiber optic cables at the backbone level. They collected metadata in bulk. Backbone providers are prime targets for intelligence collection precisely because all traffic flows through them. A National Security Letter compels cooperation and comes with a gag order. The provider cannot tell you they are being tapped.

Encryption protects your content at this layer. It does not protect the fact that communication happened.

The Combinations

Here is what each setup actually exposes.

No CDN, direct to a German server. TLS terminates at your server. No intermediary sees plaintext. Backbone providers see encrypted traffic and metadata only. This is the most private option. The trade-off is no DDoS protection and no edge caching. Your server handles all traffic directly.

EU CDN with EU edge server, to a German server. TLS terminates at an EU edge server operated by an EU company. They see plaintext, but under EU law. The connection from edge to your origin is separately encrypted. Backbone metadata is still visible. This is a reasonable balance of privacy and performance.

EU CDN with US edge server, to a German server. TLS terminates at a US-based edge server operated by an EU company. The hardware is on US soil, but the encryption keys are held by the EU company. The CLOUD Act does not apply to them. If the hardware is seized, the data is encrypted. To compel decryption, authorities would need to go through EU legal process. This is meaningfully different from using a US company.

US CDN to a German server. TLS terminates at a US company fully subject to US surveillance law. They see all your traffic in plaintext regardless of where your origin server is. Choosing a German server for your origin does not protect the traffic that the US CDN has already decrypted. This negates the jurisdictional advantage of EU hosting.

US hosting provider, any data center. The CLOUD Act applies to the company, not the location. A US hosting provider with a European data center is still compelled to hand over data under US law. The data center location provides no protection.

What We Recommend

Hosting: Hetzner

Hetzner is a German company founded in 1997. They own and operate their own data centers in Falkenstein and Nuremberg, Germany, and Helsinki, Finland. Their own hardware. Their own network. No middleman. No US parent company. No venture capital investors who might push for a sale to a US acquirer.

They are not a privacy company. They are a hosting company that happens to be German, which means they operate under the legal framework described above. They comply with valid German legal requests. They do not mine your data, scan your files, train AI models on your content, or sell information about you to advertisers. They provide infrastructure. What you run on it is your business.

Their data centers are ISO 27001 certified. Pricing starts under €4/month for a cloud instance with NVMe storage, a public IP, and 20 TB of included traffic. Billing is hourly with a monthly cap. No surprises.

When you create a Hetzner server, you choose the data center location. They also offer US and Singapore locations. If privacy is why you are here, choose Falkenstein or Nuremberg. That is the entire point.

A single Hetzner cloud instance is enough to run your entire self-hosted stack:

• Nextcloud: file sync, calendar, contacts, photo backup
• WireGuard: encrypted VPN tunnel to your server from anywhere
• Podman: containers without a daemon
• Git server: Gitea or Forgejo for code hosting
• Website: Caddy or Nginx for your web presence

All of this on one machine. Under €10/month. German jurisdiction. You own the stack.

CDN: Bunny.net

If you need a CDN for performance or DDoS protection, Bunny.net is a Slovenian company operating under EU law. The CLOUD Act does not apply to them. Their encryption keys are outside US jurisdiction. It is not perfect, no CDN is because all CDNs decrypt at the edge, but it keeps the plaintext under EU law rather than handing it to a US company.

A Note on Cloudflare

Cloudflare is an excellent service. Their DDoS protection is best in class. Their global network spans over 285 cities. Their free tier is generous. For many use cases, Cloudflare is the right choice and there is nothing wrong with using it.

But Cloudflare is a US company. If you are specifically trying to protect intellectual property, proprietary source code, or sensitive user data from warrantless access, that matters. It is not a flaw in their service. It is a consequence of their jurisdiction. The CLOUD Act applies to them because of where they are incorporated, not because of anything they have done wrong.

For public-facing content like marketing sites, blogs, and documentation, Cloudflare is fine. The content is public anyway. For infrastructure that handles proprietary code, private user data, or trade secrets, the jurisdiction question becomes relevant.

Bunny.net also happens to be cheaper for most use cases. Their pricing is pay-as-you-go at $0.01 per GB in North America and Europe, with no request fees and no tier jumps. Cloudflare’s free tier is great until you outgrow it, then it jumps to $20/month (Pro), $200/month (Business), or $2,000+ (Enterprise). Bunny.net’s average global latency is 24ms across 119 PoPs, comparable to or faster than Cloudflare’s network for pure CDN delivery. So you are not sacrificing performance or paying more. You are getting EU jurisdiction as a bonus.

No CDN

If privacy is your absolute priority, skip the CDN entirely. Let TLS terminate at your server in Germany. No intermediary sees plaintext. Use Hetzner’s built-in firewall and keep your attack surface small. This is the strongest configuration.

What About Home Servers?

Home servers are great for long-term storage and full physical control. But they come with trade-offs.

• Uptime. Your home internet goes down. Your power goes out. A data center has redundant power, redundant networking, and 24/7 staff.
• Static IP. Most residential ISPs give you a dynamic IP. Reliable hosting needs a static one.
• Port forwarding. Exposing services on your home network requires opening ports. Done wrong, this creates security risks.
• Bandwidth. Residential upload speeds are often a fraction of download speeds. A data center has symmetric gigabit connectivity.

The best setup for many people is both. A cloud server for services that need to be always-on and publicly reachable. A home server for bulk storage and backups. Connect them with WireGuard and they act as one network.

This Is Not About Hiding

To be clear: this is not about evading law enforcement. If a German court issues a valid legal request, Hetzner complies. If an EU court orders Bunny.net to hand over data, they comply. That is how the rule of law works and that is how it should work.

This is about the difference between lawful, targeted investigation and warrantless mass collection. It is about legal systems that require judicial authorization versus legal systems that operate in secret. It is about your right to know when your data has been requested versus a gag order that ensures you never find out.

If you run a business, your customers trust you with their data. If you run a community, your members trust you with theirs. That trust means choosing infrastructure where their data is protected by laws that were written to protect people, not laws that were written to surveil them.

Get Started

Setting up a server on Hetzner takes about two minutes.

1. Create a Hetzner Cloud account (use our link for $20 free credit)
2. Create a new project
3. Add your SSH public key
4. Create a server. Choose Ubuntu 24.04, pick Falkenstein or Nuremberg
5. SSH in and start building

ssh root@YOUR_SERVER_IP

From there, install whatever you need. Our other articles walk through setting up Nextcloud, WireGuard, and the rest of the stack step by step.

The infrastructure you choose is a statement about what you believe your users deserve. Choose accordingly.