Why I'm Moving jcoffey.dev, coffeylabs.org, and My Email Out of the United States

I've spent over thirty years building, breaking, and rebuilding infrastructure. I've raced racks against deadlines, migrated mail servers at 2 a.m., and argued with vendors about SLAs until I was hoarse. In all that time, "where" a workload lived was almost always a technical question: latency, cost, compliance, redundancy. It was never really a question about who governs the wire the packets travel over, or what a government could compel a provider to hand over — or shut off — without me ever knowing.

That's changed. And so I'm moving jcoffey.dev and coffeylabs.org to hosting in Germany, and my mail — the actual mailboxes, the Stalwart instance, the JMAP store behind ihasmail — to the Netherlands. Not because either country is a magic bullet. Because I've done the math, technical and otherwise, and the math has shifted.

This isn't a hot take, it's a homelab decision

I want to be honest about what this is and isn't. This isn't a manifesto. I'm not telling anyone else what to do with their infrastructure, and I'm not pretending this is some grand act of resistance — it's a guy with a Proxmox cluster in his garage deciding where to point his DNS. But I've spent my career telling other engineers that "it's just a technical decision" is often a cop-out, that architecture is never fully separable from the world it sits in. I'd be a hypocrite not to apply that to myself.

The hassle, plainly stated

Let's start with what this actually costs me, because I think too many "principled" infrastructure posts skip this part, and that skip is what makes them unconvincing.

Latency is real. I'm in Phoenix. A round trip to a German data center adds real milliseconds that a US East Coast or even a Denver colo never would. For jcoffey.dev, a mostly static personal site, that's a rounding error — nobody notices an extra 90ms on a blog post about my M1000e chassis. For anything more interactive I build under Coffey-Labs, it's a design constraint I now have to account for: more aggressive edge caching, more thought about what has to be dynamic versus what can be baked at build time, and accepting that "closest possible node" is no longer the only variable in that equation.

Mail latency and deliverability are their own headache. Moving my actual mail infrastructure — not just a website — to the Netherlands means re-earning sender reputation, re-validating SPF/DKIM/DMARC from a new IP range, and living through the awkward weeks where some receiving mail servers are suspicious of a "new" sending host, even though it's the same person behind it who's been running Stalwart competently for years. Anyone who has migrated a mail server knows this isn't a DNS cutover, it's a slow rebuild of trust with every other mail system on the internet.

The cost isn't nothing. European hosting, especially hosting from providers with a genuine privacy and data-protection posture rather than a US company with a German subsidiary, tends to run a premium over the commodity US cloud I could otherwise lean on. Add in the operational overhead of managing infrastructure across a timezone that's most awake while I'm asleep, and this is not the cheapest or easiest path available to me. I know that. I priced it out before I committed to it.

And there's the plain hassle of it. New providers, new billing relationships, new support processes in a different regulatory language, new runbooks, new disaster recovery assumptions. I get to redo work I already did once, competently, on infrastructure that mostly just worked.

Why I'm doing it anyway

None of that hassle is imaginary, and I'm not going to pretend it is. But I keep coming back to a question I ask my own team at work when we're evaluating any platform decision: what are you actually optimizing for, and does the thing you picked actually optimize for it?

For years, I optimized for latency and cost, full stop, because the governance question wasn't a live variable — or at least, it didn't feel like one. That's no longer true for me. Right now, in this political moment, I don't have confidence that data and infrastructure sitting under US jurisdiction is insulated from a rapidly shifting legal and political environment — one where the rules about what can be compelled, surveilled, or seized from a hosting provider or mail provider, without meaningful notice to the person whose data it is, feel less settled than they did even a couple of years ago. I'm not making a claim about any single law or any single agency. I'm making a claim about trajectory and uncertainty, and about not wanting my personal site and my email — the place where my identity, my correspondence, and increasingly my open-source projects live — to be a rounding error in someone else's much larger fight.

Germany and the Netherlands aren't perfect jurisdictions either — no jurisdiction is. But they sit inside a regulatory framework, the GDPR and the broader EU data-protection apparatus, that was built explicitly around the idea that a person's data belongs to them first, and to the platform or state second. That's a meaningfully different starting assumption than the one I'd be operating under at home right now. I chose Germany for the general hosting because of its strong data-protection culture and the maturity of its infrastructure providers, and the Netherlands for mail because of its long history as a hub for privacy-respecting mail and network infrastructure, with providers who've built their reputation on exactly the kind of resilience and transparency I want backing something as personal as my inbox.

What I'm not saying

I'm not saying every American should pack up their infrastructure and move it to Frankfurt. I'm not saying US-based hosting is compromised today, in some concrete, provable sense — I don't have evidence of that, and I wouldn't write it if I did. What I'm saying is narrower and more personal: given the uncertainty I currently see, and given that I have the technical skill, the homelab background, and honestly the stubbornness to absorb the hassle, I'd rather pay the latency tax and the migration tax now, on my own terms, than find out later that I needed to and didn't have the runway to do it calmly.

That's really what this comes down to. Thirty years in this field has taught me that the best migrations are the ones you do before you're forced into them — the planned cutover beats the emergency one, every single time, whether you're moving off end-of-life hardware or out from under a jurisdiction you're no longer sure you trust. This is that same instinct, applied one level up the stack from where I usually apply it.

So: jcoffey.dev and coffeylabs.org are headed to Germany. My mail is headed to the Netherlands. It'll cost me more, it'll be slower by a few dozen milliseconds nobody but me will ever measure, and I'll spend a few weekends rebuilding sender reputation and re-testing failover I already had working once. I think it's worth it. Not because I'm certain something bad is coming — but because for the first time in my career, I'm not certain it isn't, and that uncertainty alone is reason enough to move.