The fire declared on May 7th at the NorthC data center in Almere, Netherlands, has provided one of those lessons that the cloud industry often explains in presentations but can only truly understand when a crisis occurs. Digital infrastructure also burns, evacuates, becomes inaccessible, and can leave companies, universities, government agencies, and professionals without service—those who until then took for granted the availability of their systems.
In that context, the public testimony of Jeroen Derks, a PHP and Laravel specialist, has given a name to a less visible part of the technical response. After the fire, Derks explained on LinkedIn that his managed server by Stackscale was operational again at a different location “in record time.” While he was worried about losing email access, the engineering and support team was working behind the scenes to restore the service.
His message, with a phrase as simple as it is powerful, “Turns out, Stackscale is fireproof,” summarizes something any infrastructure provider should be able to demonstrate: business continuity isn’t measured by marketing brochures but by the ability to respond when a physical location fails.
A fire that reminded us of the physical side of the cloud
The fire was reported on the morning of Thursday, May 7, 2026, at NorthC Datacenters’ facilities in Rondebeltweg, within the Sallandsekant industrial park in Almere Stad. NorthC reported that the fire started around 8:45 a.m. and that everyone present was evacuated in time. Authorities activated an NL-Alert for nearby residents due to smoke, and the situation was initially escalated to GRIP 1, a level of emergency coordination used in the Netherlands.
The incident was significant. Various Dutch and international media reported issues with digital services linked to public, educational, and corporate organizations. Utrecht University reported impacts on its network, applications, and websites, affecting daily work, research, and teaching. Other outlets also noted disruptions in public transportation, clinics, and administrative agencies.
The event exposed an uncomfortable reality: cloud services, hosting, connectivity, and digital platforms depend on specific buildings, electrical systems, technical rooms, and equipment that, despite redundancy, can become inaccessible for hours or days. The cloud doesn’t float in the air; it resides in data centers with physical risks—from fires to electrical failures, floods, fiber cuts, or cooling issues.
In Almere’s case, Techzine reported that complete recovery of the center could take up to 72 hours, as NorthC worked on inspections, damage control, and communication with clients. For any affected business, this window may be manageable if a proven recovery plan exists; it can be critical if everything depends on a single location.
Restoring a server isn’t just turning on another machine
The story shared by Jeroen Derks is especially relevant because it brings the debate down to earth. Business continuity isn’t just about having backups. It’s about knowing where they are, when they were created, whether they are consistent, how long recovery takes, what dependencies the service has, which DNS settings need updating, which networks to bring up, what data might be lost, and which clients need to be notified.
Recovering a server in another location after a data center incident requires technical and operational coordination. You need to assess the impacted service, locate backups or replicas, provision alternative capacity, rebuild machines, validate systems, check connectivity, and verify email, databases, certificates, firewalls, storage, and monitoring. Sometimes, you also have to work without immediate access to the original building.
This is where a provider that merely hosts infrastructure differs from one that operates with a continuity mindset. The response doesn’t depend solely on available hardware; it depends on processes, people, documentation, automation, and accumulated experience. It also depends on having multiple locations and the ability to move workloads quickly when a site is compromised.
Derks’ public acknowledgment is valuable because it doesn’t come from a corporate statement. It’s the reaction of a client who experienced a real outage and saw their service restored at another location. In such situations, trust is built through execution, not promises.
Resilience must be designed before a crisis occurs
The NorthC fire teaches a clear lesson for any organization reliant on digital infrastructure: resilience isn’t improvised during an incident. It’s designed beforehand. And it’s tested beforehand.
Many companies believe they have continuity because they perform backups. That’s a first step but not enough. A backup that’s never been restored is just hope, not a guarantee. A recovery plan that exists only on paper without responsible parties, timelines, and regular testing may fail when it’s most needed. Concentrating critical architecture in a single data center turns any physical incident into a business risk.
The right strategy depends on the type of workload. Not all services require active-active high availability across multiple centers. Not everyone needs synchronous replication, geographical clustering, or complex architectures. But all should know their RPO and RTO: how much data can be lost and how long the maximum outage can last.
Professional email, an e-commerce store, a SaaS platform, an ERP, a customer database, or an corporate website—all have different criticalities. Still, it’s essential to answer concrete questions: where are the data stored, what happens if the primary data center becomes inaccessible, who executes recovery, how long it takes, how users are informed, and when was the last test conducted.
The Almere case also underscores the importance of location diversification. In Europe, many companies have adopted cloud or colocation solutions thinking about latency, cost, or certifications but haven’t designed architectures that can withstand physical site failures. Having multiple data centers, redundant networks, and geographically separated copies isn’t a luxury if the service supports critical activity.
Lessons for providers and clients
For infrastructure providers, incidents like Almere’s highlight the need to review emergency plans, communication strategies, coordination with emergency services, access controls, client management, service prioritization, and cross-site recovery capabilities. Transparency also matters. During a crisis, clients need frequent, clear, and useful information—even if all answers aren’t available yet.
For clients, the lesson is equally demanding. You can’t delegate all continuity to the provider without understanding your own architecture. It’s necessary to contract the appropriate level of resilience, review backups, request restoration tests, document dependencies, and avoid selecting solely based on cost. High availability isn’t automatic; it must be designed, contracted, and maintained.
The experience of Stackscale with Jeroen Derks’s server illustrates the positive side of a crisis: with the right team, procedures, and multiple locations, affected workloads can be recovered, minimizing customer impact. It also demonstrates the value of the human teams behind the cloud. In his post, Derks praised the engineers and support staff, crediting their swift response under difficult conditions.
This recognition is vital because business continuity is often perceived as a cold technical layer. In reality, during a serious incident, it’s capable people who make the difference—those who can make decisions, coordinate, and act quickly. Automation helps, but someone must know the platform, prioritize actions, communicate effectively, and ensure service recovery.
The Almere fire won’t be the last physical incident affecting a European data center. Reliance on digital infrastructure will only grow, along with exposure to failures that may seem unlikely until they happen. The question for organizations and providers isn’t whether problems will occur but whether their architecture and teams are prepared when they do.
Frequently Asked Questions
What happened at the NorthC data center in Almere?
On May 7, 2026, a fire was reported at NorthC Datacenters in Rondebeltweg, Almere. The building was evacuated, and emergency alerts were issued due to smoke.
What’s Stackscale’s connection to this incident?
A Stackscale client, Jeroen Derks, publicly explained that his server was operational again at another location after the fire and thanked the technical and support team for their quick response.
What’s the difference between backups and business continuity?
Backups are copies of data. Business continuity includes restoration, alternative infrastructure, networking, recovery times, communication, and periodic testing.
What should a company review after an incident like this?
They should check their RPO and RTO, backup locations, restoration tests, dependence on a single data center, communication plans, and the actual level of high availability contracted.