Last week, the internet caught fire. Again.
Critical vulnerabilities in PHP, the programming language powering millions of websites, sent hosting providers and system administrators scrambling to deploy emergency patches. A separate Node.js security issue added to the chaos. AI-assisted research helped uncover weaknesses in widely used software, reminding businesses how much they depend on technology they rarely think about.
Here at Trivera, our technical team spent much of the week applying updates, implementing temporary protections, and keeping the more than 150 websites and applications we host secure and operational.
Watching this unfold got me thinking about 1996, when we first started building websites. And how, despite nearly 30 years of technological advances, some things haven’t changed much.
Back then, there weren’t many hosting options in Southeastern Wisconsin. There were only a handful of Internet service providers, and even fewer offered website hosting. And, most of them shared a single cable connecting Milwaukee to the internet backbone.
One day an excavator working somewhere in Illinois cut that cable. Just like that, Milwaukee was offline for the better part of a day. No cyberattack. No ransomware. Just somebody digging a hole in the wrong place.
But what ultimately convinced us to take control of our clients’ hosting wasn’t the excavator. It was discovering that when a client’s website went down, our hosting provider wouldn’t give us a phone number to call. We were responsible to our clients but had no control over getting their websites back online.
So in 1998, we decided to host our client websites ourselves. Not because we wanted to become a hosting company, but because we wanted to take care of the websites we were building.
Nearly 30 years later, that decision still shapes how Trivera operates.
Thirty Years of New Technology and New Ways for Things to Go Wrong
In the early days, websites were mostly static HTML pages. Keeping servers running and internet connections working was the primary challenge. As websites became more sophisticated, so did the opportunities for things to go wrong.
- The 1990s brought infrastructure problems. Servers crashed, connections failed, and hosting providers sometimes disappeared overnight. Simply keeping a website accessible was an accomplishment.
- The 2000s brought dynamic websites. Databases, content management systems, PHP, and e-commerce introduced new capabilities, along with vulnerabilities and compatibility issues.
- The 2010s brought interconnected systems. Cloud computing, plugins, APIs, payment processors, and marketing platforms meant problems elsewhere could suddenly become your website’s problem.
- The 2020s brought sophisticated cyberthreats and AI. Automated attacks grew more capable, vulnerabilities could be discovered faster, and responding quickly became increasingly important.
Every advancement made websites more powerful while introducing new responsibilities for the people taking care of them. Keeping a website running was no longer simply about maintaining its server.
Sometimes You Have 24 Hours to Prevent a Disaster
Years ago, a major Good Friday snowstorm was bearing down on Milwaukee. Trivera was hosting the website for General Mitchell International Airport, and we knew thousands of travelers would soon be searching for flight information and cancellations.
We had about 24 hours to prepare. This was long before today’s sophisticated content delivery networks and readily available load-balancing services, when a sudden traffic surge could easily overwhelm a website.
Our team configured a second server to help handle the demand, turning the primary server into a makeshift load balancer. It wasn’t an off-the-shelf solution. We engineered it because we understood what was about to happen to our client’s business.
Over the next 36 hours, the airport website handled 11 million hits. And it stayed up.
More recently, we took a similar proactive approach with George Webb as the Brewers approached the winning streak that triggers its legendary free-burger promotion. As I mentioned in last week’s blog, knowing what was coming allowed us to prepare their website before the traffic arrived.
Neither situation started with a hosting emergency. Both started with understanding our clients’ businesses well enough to anticipate one.
That’s a distinction worth remembering. A hosting provider knows how much traffic your server can handle. An agency that understands your business might know when that traffic is coming.
Sometimes the Best Hosting Decision Is Not to Change Anything
Potawatomi Casino Hotel has been a Trivera client for many years. One of our earliest assignments wasn’t a marketing campaign or website redesign. It was taking responsibility for hosting their website.
Years later, Potawatomi developed its own data center infrastructure in Milwaukee. Naturally, we assumed its websites would eventually move there. Why would an organization with its own hosting capabilities continue using an outside agency?
But Potawatomi’s IT department preferred that Trivera continue hosting the casino’s website, intranet, and other web projects because of the reliability and confidence we’d established.
I always thought that was a meaningful endorsement. An organization with the resources to manage its own infrastructure chose to leave those responsibilities with us.
It wasn’t about who owned the servers. It was about who they trusted to take care of the websites.
Security Isn’t Just Something You Promise. Sometimes You Have to Prove It.
Keeping websites running is only part of the responsibility. Many of our larger clients have formal enerprise-wide cybersecurity requirements, including vulnerability scans, penetration testing, and independent security assessments. We configure and maintain our hosting environments with those requirements in mind and ensure our servers are included when clients arrange outside testing.
We’ve even had clients forward reports showing that a server failed a security assessment, only for us to investigate and discover the vulnerable server wasn’t ours. It was somewhere else in their infrastructure.
Apparently, knowing which server you’re testing is a pretty important part of website security, too.
There’s a serious point behind that humor. A clean scan doesn’t mean a website is invulnerable, and a failed scan doesn’t necessarily mean the website itself is the problem. Someone needs to understand the environment, interpret the findings, and address legitimate issues.
Security isn’t something you install once and forget. It’s an ongoing responsibility involving monitoring, testing, updating, and adapting as threats evolve.
And last week offered a dramatic reminder.
Last Week, the Internet Caught Fire Again
The PHP vulnerabilities affected technology used by WordPress, Concrete CMS, and countless custom applications. AI-assisted research helped uncover the weaknesses, demonstrating both the promise and potential danger of AI in cybersecurity. Meanwhile, a separate Node.js emergency was unfolding with considerably less attention. The combined issues were shutting down government websites across europe, the BBCs website and impacting Netflix, Wikipedia, Internet Archive’s Wayback Machine,
For Jonah, Trivera’s tech team leader and system administrator, it meant a very busy couple of days.
Jonah has managed servers for 20 years, the last 11 with Trivera. He receives alerts as vulnerabilities are disclosed, sometimes before they become widely publicized. When something serious emerges, he doesn’t wait for a website to fail. He starts figuring out what needs to be done.
This week, that meant coordinating emergency updates across 24 virtual private servers supporting approximately 150 websites and applications. And it wasn’t a matter of clicking one button.
- cPanel updates were completed by noon.
- CloudLinux and AlmaLinux patches followed as vendors released their fixes during the afternoon.
- A separate Node.js security issue required additional updates, addressed by evening.
- Four rounds of patches were manually applied across the VPS environments as fixes became available.
And when another vulnerability emerged a few days later without official patches, Jonah manually implemented temporary configuration changes across the servers to mitigate the risk.
The result? No compromised websites. No downtime. And more than 150 websites continuing to operate throughout an extraordinary series of security updates.
No responsible hosting provider can guarantee that nothing will ever go wrong. But this demonstrates the difference between having a website sitting on a server somewhere, hoping experienced people are actively taking care of it and knowing the name…and having the phone number…of an individual who you know is taking personal repsosibility.
Taking Care of the Website Is Only Half the Job
While Jonah was working through the emergency patches, Jeff and Jamie were personally contacting our clients. The PHP vulnerabilities were making headlines, and rather than waiting for clients to wonder whether their websites were affected, we wanted them to hear from us first.
Only one client had contacted us with concerns before that outreach began. The others heard from us first, and numerous clients responded to say how much they appreciated being kept informed.
Our clients didn’t need to understand the differences between PHP, cPanel, CloudLinux, or AlmaLinux. They needed to know somebody understood the problem, was paying attention, and was taking care of it.
That’s what we told them. And that’s what we were doing.
Because taking care of a website isn’t just about protecting technology. It’s about taking care of the people and businesses depending on it.
What This Means for You
Business owners and marketing executives spend considerable time thinking about what their websites should accomplish: traffic, leads, conversions, customer experience, search visibility, and increasingly, AI visibility. But how often do they consider who’s actually taking care of the website itself?
If you’re not sure, here are six questions worth asking.
- Who is personally accountable for your website? Beyond the company on the hosting invoice, who is responsible for keeping it running, secure, and maintained?
- How quickly are security vulnerabilities addressed? Is someone monitoring emerging threats, applying patches, and implementing temporary protections when fixes aren’t yet available?
- Does your hosting team understand your business? Can they anticipate traffic surges caused by promotions or emergencies, or do they respond only after your website crashes?
- Who’s watching the systems your website depends on? If a third-party API, reservation system, or data feed fails, who notices and helps resolve it?
- Can your hosting provider demonstrate that your website meets your security requirements? Are your servers included in required tests, and can someone interpret and address the findings?
- When something serious happens, who contacts whom? Will your agency proactively explain what’s happening, or will you have to call after hearing about the problem on the news?
We’ve spent nearly 30 years learning that website hosting isn’t really about servers, bandwidth, or technology. Those things matter, but they’re tools, not the objective.
The objective is making sure the websites our clients depend on continue doing what they’re supposed to do, even when circumstances make that difficult.
Thirty years ago, the threat might have been an excavator cutting a cable in Illinois. Today, it might be an AI-discovered vulnerability affecting millions of servers around the world.
The technology has changed dramatically. The responsibility hasn’t.
The next time the internet catches fire, you shouldn’t have to wonder whether somebody is taking care of your website. You should already know.
And if you’re not sure, that’s a pretty good reason to start a conversation with Trivera.
