Dora NodaIn the early hours of January 3, 2026, a fire on a cable bridge over Berlin's Teltow Canal cut power to roughly 45,000 households and more than 2,200 businesses across the city's southwest. It took four days — until January 7 — to fully restore electricity, making it the longest blackout in Berlin since 1945. And the group that claimed responsibility said it struck for a reason this industry should sit with: the electricity hunger of AI data centers.
Here is the verdict up front. Every infrastructure postmortem you have ever read assumes the failure starts inside your systems — a bad deploy, a saturated disk, a misconfigured route. Berlin's blackout started outside all of it, at the cable bridge feeding a substation, and no amount of in-cluster redundancy would have helped anything plugged into that grid segment. The only defense that would have mattered is the oldest one in distributed systems: not having everything in one place. A self-hosted fleet spread across separate regions and providers has that property by construction — and for the first time, there is a physical-security argument for it, not just an availability-zone one.
What actually happened on January 3
The facts, because the rest of the post depends on them being concrete rather than atmospheric:
- The target: a cable bridge near the Lichterfelde combined heat-and-power station in southwest Berlin, carrying high-voltage lines into a distribution substation. One bridge, one substation, one fire.
- The blast radius: up to 45,000 households and around 2,200 businesses across four districts, without power — and in January, without heat — for up to four days. Grid operator Stromnetz Berlin warned early that repairs "will take a very long time," and it was right: crews had to lay new underground cables.
- The cause: arson, confirmed quickly by investigators. A claim of responsibility appeared online and was authenticated by Berlin's security authorities. The case was transferred to the Public Prosecutor General on suspicion of terrorist organization membership.
- The claimants: Vulkangruppe — the "Volcano Group" — a far-left extremist network that cited the role of fossil fuels and AI in accelerating the climate crisis. This was not their first grid-adjacent action: the same network was blamed for a 2024 arson attack near Tesla's Berlin-area factory, and a September 2025 attack that left around 20,000 Berliners without power.
- The reaction: Berlin's mayor called it terrorism, and the city's interior senator confirmed the claim letter's authenticity.
Two things make this more than a local crime story. First, the duration: four days is not a failover event, it is a relocation event — nothing running in the affected districts computed anything for the better part of a working week. Second, the motive names our industry's infrastructure directly. Concentrated compute is now, explicitly, somebody's symbolic target.
Why AI data centers got named
It is tempting to dismiss the motive as fringe rationalization. That would be a mistake, because the underlying grievance — that AI compute demand is reshaping electricity grids — is one that grid operators themselves now state in dry regulatory language.
North America's reliability overseer, NERC, has issued repeated alerts warning that large, volatile data-center loads threaten grid stability, noting that operators lack the models and procedures to manage "computational loads" that ramp the way training and inference clusters do. The pattern is the same on both sides of the Atlantic: a hyperscale AI campus concentrates tens or hundreds of megawatts in a single grid interconnection point, in a single municipality, behind a single set of feeders. That concentration is an engineering decision with a physical footprint — new substations, new transmission corridors, visible construction — and anything with a visible physical footprint can be picketed, litigated, or, as Berlin showed, burned.
Now put the attacker's logic next to the engineer's logic. The engineer centralizes compute to amortize power contracts, cooling, and fiber. The attacker looks at the same map and sees one cable bridge whose destruction darkens four districts and makes international news. Concentration is efficient right up until someone prices your single point of failure differently than you did.
This is also not an isolated data point. Spain and Portugal's massive April 2025 blackout — whatever its ultimate technical cause — already demonstrated how a grid-scale event cascades through everything plugged into it, including data centers with supposedly robust backup. Add Berlin, and 2025–2026 reads as the period when "the grid will be there" quietly stopped being a safe assumption in infrastructure planning.
The concentration problem, stated as blast-radius math
Strip the politics out and the Berlin attack is a clean demonstration of correlated failure — the thing every availability calculation pretends it has bounded:
| Concentrated campus / single-region deployment | Distributed self-hosted fleet | |
|---|---|---|
| Failure unit | One grid segment, one substation, one cable bridge | One region or provider among several |
| Berlin-equivalent blast radius | Everything dark for four days | The affected region's nodes go dark; the rest keep serving |
| Recovery mode | Wait for the utility (you cannot fix their cables) | Re-route traffic, re-provision capacity elsewhere |
| Symbolic value to an attacker | High — one strike, international headlines | Negligible — no single pool is big enough to be worth naming |
| Who decides you are back | Stromnetz Berlin's repair crews | Your own failover runbook |
The last row is the one that should worry a single-region operator most. Four days of downtime with zero agency: your status page says "upstream power issue," your customers leave, and there is nothing to do but watch cable-laying. A fleet spread across, say, Hetzner's Nuremberg and Falkenstein regions plus a second provider still loses the Berlin-adjacent capacity — physics is physics — but it keeps serving traffic from everywhere else within minutes, and it recovers on its own schedule by provisioning replacement nodes, not on the utility's.
Note the asymmetry that favors the small operator here. A hyperscale AI campus cannot be "a little bit distributed" — its whole economic logic is concentration. A modest self-hosted fleet of a handful of nodes is already small enough per site that spreading it costs almost nothing extra: the same machines, just in two or three regions instead of one, behind DNS or load-balancer failover you were going to configure anyway. Distribution is a rounding error on a small fleet's bill and an existential redesign for a gigawatt campus. For once, the little guy holds the structurally cheaper hand.
What "distributed by default" concretely requires
"Multi-region" is easy to say and easy to fake — a second region you have never failed over to is a hope, not a design. For a Cluster-API-managed fleet on owned or rented bare metal, the concrete pieces are unglamorous and mostly already standard practice:
- Node pools in at least two failure-independent regions — different grid segments, ideally different providers or at least different Hetzner regions (Nuremberg vs. Falkenstein vs. Helsinki), so one cable bridge cannot take the whole fleet. Cluster API's whole premise — declarative
ClusterandMachineDeploymentobjects per site — makes the second region a config change, not a second platform. - Traffic that can actually move — DNS-based failover or a load balancer with health checks, tested by actually draining a region, not by reading the docs. Berlin gave four days' notice of nothing; failover that has never been drilled will not survive first contact with a real outage.
- Data that survives the region, not just the node — replicated or restorable state (off-site backups at minimum, synchronously replicated where the workload demands it), because stateless failover over a dead database is just a faster error page.
- A control plane that outlives any one site — the management cluster itself spread or recoverable, so losing a region does not also lose the tooling you need to re-provision into the survivors.
None of this is exotic. That is precisely the point: the fleet that survives a Berlin is not the one with the fanciest redundancy technology, it is the one whose ordinary topology already assumes sites fail. "Distributed by default" means the failover path is the everyday path, exercised constantly, not a break-glass runbook gathering dust.
The honest limits: distribution is not immunity
A skeptical reader should push back here, and the pushback is fair. Spreading nodes across regions does not make you immune to anything — it converts total failure into partial failure, which is a strictly better but still bounded win:
- Small nodes still plug into local grids. A Hetzner region in Falkenstein is itself concentrated infrastructure; a sufficiently determined attacker or a sufficiently bad storm can darken it too. Distribution narrows the blast radius, it does not abolish it.
- Failover has real costs. Cross-region replication bandwidth, data-transfer fees where they apply, the operational overhead of watching two sites instead of one, and the latency tax of synchronous replication if your workload needs it. Anyone telling you multi-region is free is selling something.
- Correlated failures can span regions. A software bug in your own platform, a bad base image, an expired certificate — these fail everywhere simultaneously no matter how many grids you span. Berlin argues for geographic distribution; it says nothing about the failure modes you ship yourself.
- Four days tests more than routing. A region lost for most of a working week stresses backups, on-call rotations, customer communication, and capacity headroom in the surviving regions — the organizational half of resilience that no topology diagram captures.
The claim is not "distribute and stop worrying." The claim is narrower and still new: physical sabotage of concentrated compute has moved from hypothetical to demonstrated, the demonstrated motive names AI infrastructure specifically, and the cheapest available hedge — not putting all of your modest fleet in one grid segment — is one that small self-hosted operators can afford more easily than the hyperscalers they compete with.
The grid is now part of your threat model
For most of commercial computing history, the power grid sat below the bottom line of every architecture diagram — assumed, unexamined, somebody else's problem. Berlin's January blackout redrew that line. A single cable bridge, a few liters of accelerant, a four-day outage, and a claim letter naming AI compute: that is a complete demonstration that concentrated infrastructure can be targeted as concentrated infrastructure, whatever the attacker's ideology.
The hyperscalers will respond the way they respond to everything — with money: private substations, on-site generation, hardened perimeters around campuses that keep getting bigger and more conspicuous. That is a reasonable strategy if you are building gigawatts. If you are running a PaaS on a fleet of machines you own or rent across a few regions, your version of the same strategy is cheaper and arguably stronger: be nowhere in particular. No single site big enough to matter, no single grid segment that can silence you, no single pool worth naming in a letter.
Availability zones were the industry's answer to "what if a building fails." Regions were the answer to "what if a city fails." Berlin 2026 is the first draft of the answer to "what if someone fails it on purpose" — and the draft says: don't be in one place.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. A Cluster-API-managed fleet across independent regions is how that fleet survives a Berlin. Star the repo on GitHub or deploy your first app today.
