Hosting Horror Stories: Why It Matters Where Your App Runs

Infrastructure is invisible -- until it breaks. And then it's the only thing you can see. And your customers can see it too.

Over the years of building web and mobile applications, we've encountered hosting solutions that would surprise us, if anything could still surprise us after all this time. From servers that physically disappeared to hosting providers that financially disappeared. Here are a few stories that taught us infrastructure really isn't where you cut costs.

The Laptop Under the Desk

This is a story you wouldn't believe if it weren't true. We took over a project from a small agency -- an internal business management system for tracking orders. It ran reliably. Until one day in August, it stopped.

We started investigating. DNS pointed to an IP address that didn't match any known hosting provider. After a series of phone calls, we discovered the truth: the application was running on the developer's old laptop. On his desk. In the office.

The developer had left for vacation in Croatia. On his way out of the office, he knocked the power cable. The laptop ran out of battery. The application went down. And because the developer was the only person who knew about this server (and had the password), nobody could restart it.

Two weeks without the internal system, because someone wanted to save on hosting. The monthly cost of a real server would have been a fraction of what that two-week outage cost in lost productivity.

Want the best part? The laptop wasn't even backed up. If the hard drive had failed instead of the battery dying, the data would have been gone forever.

"Unlimited Hosting" for Two Dollars

A client launched an online store. They chose a hosting provider because it was the cheapest -- roughly two dollars a month with the promise of "unlimited space and bandwidth." Sounded great. The first month went smoothly.

Then they launched a marketing campaign. Social media ads, newsletter, discount promotion. Traffic climbed to a hundred concurrent users. The site went down.

They contacted the host. The response: "Your plan is optimized for smaller projects. For higher loads, we recommend upgrading to the business plan." The business plan: twenty dollars a month. Still cheap. They upgraded. At two hundred concurrent users, it crashed again.

"Unlimited" turned out to be considerably more limited than expected. In the terms of service that nobody reads, it stated: shared hosting, maximum 10% CPU of one core, 256 MB RAM per account, 20 concurrent database connections. Adequate for static pages. Completely insufficient for an e-commerce site with dynamic content, search, and a shopping cart.

The client came to us on a Friday evening with a non-functioning store in the middle of a campaign. We handled the migration to a proper VPS over the weekend. Meanwhile, the campaign kept running and sending people to a broken website. Ad spend going straight down the drain.

The Hosting Provider That Went Bankrupt Overnight

A small local hosting provider. Low prices, friendly support, working services. The client hosted their website and database there for three years without issues.

One morning, the website stopped working. The provider's phone number no longer existed. The provider's website was offline. Emails bounced. After two days of investigation, we discovered the company had ceased operations. Overnight. Without notifying customers. Servers shut off.

The client's data? On those powered-down servers. Backups? The client had them. The last backup was four months old. Four months of data -- orders, customer accounts, content changes -- gone.

We restored the website from the backup on new hosting within a day. But those four months of data are gone forever. The client learned two lessons at once: make regular backups and don't rely on a single small provider with no guarantees.

One for All, All for One (in the Bad Sense)

Shared hosting. Dozens of websites on a single server. Efficient, cheap, and usually fine. Usually.

A client had their company website on shared hosting. Nothing big, nothing demanding. One day, Google Chrome started displaying a warning: "This site may harm your computer." The website was blacklisted.

The cause? A completely different website on the same server had a security vulnerability in WordPress. Attackers exploited it to gain access to the server and infected every website on it. Including our client's perfectly innocent site.

Removing the malware, scanning, submitting a review request to Google, waiting for the warning to be lifted -- the whole process took two weeks. Two weeks where every visitor to the website saw a red warning page. How many potential customers it scared away can only be estimated.

The client did nothing wrong. Their website was clean, updated, secured. But they shared a server with someone who wasn't.

FTP and Nothing Else

An application deployed via FTP. The developer uploads files, overwrites production, done. No staging environment. No testing before deployment. No rollback. No version control on the server.

One day, the developer uploaded the wrong version. With a bug that broke the payment process. It was discovered six hours later, because nobody monitored production. And because there was no rollback capability, the developer had to fix the bug, test locally (hopefully), and re-upload via FTP.

Total: six hours of non-functional payments and another five hours for the fix and deployment. Eleven hours during which the store couldn't process a single order.

With a modern deployment pipeline, rolling back to the previous version would have taken minutes. But FTP deployment doesn't offer rollbacks. Once you overwrite the files, the previous version ceases to exist.

The Database with an Expiration Date

A startup that wanted to save on everything. Production database on a free tier of a cloud service. A free tier that came with a condition: after thirty days of inactivity, the database gets automatically deleted.

"Inactivity" in this case didn't mean no users. It meant no connections from the provider's admin panel. The application connected to the database normally and writes were happening. But the provider assessed the account as inactive based on a different criterion.

After thirty days, a warning email arrived. It landed in spam. After another seven days: database deleted. Production data, user accounts, transaction history -- all of it.

Backups? On the same free tier. Deleted along with the database.

The Lesson: Infrastructure Isn't Where You Save Money

All these stories share one thing: the attempt to save money on infrastructure. And in every case, that "savings" ended up costing many times more than a decent solution would have from the start.

What every project should have at minimum:

Reliable hosting with guaranteed uptime and support. Not the cheapest, not the most expensive. Appropriate for the size and demands of the project.

Automated backups stored separately from production. Daily. Tested. Because a backup you've never tried to restore isn't a backup -- it's hope.

A deployment pipeline with rollback capability. It doesn't have to be complicated. Git, a staging environment, and automated deployment can be achieved even with simple tooling.

Monitoring. At least the basics -- you know the site is running, you know it's responding. Because finding out about a six-hour outage from a customer's email isn't monitoring.

And isolation. Your project should run in its own environment, where it can't be affected by a security vulnerability on a neighboring website.

Infrastructure is the foundation everything else stands on. Without a stable foundation, it doesn't matter how beautiful the design is or how clever the code is. When the server isn't running, nothing is running.