Years ago, I wrote an article called “Low-Cost Web Hosting and Why You Should Spend a Little More.”
At the time, Phillips Web Development Company was building and hosting WordPress websites for clients, and I regularly found myself having the same conversation: why should a business spend $60 or more per month on hosting when another company was advertising hosting for a few dollars?
My argument was that hosting was the foundation of your website. Performance, reliability, security, available resources, and support all depended to some degree on the infrastructure underneath it.
I still believe that.
But if I wrote that article today, I would make a very different argument.
Because the infrastructure has changed.
In fact, the Phillips WDC website you’re reading right now costs us essentially nothing to host.
And I think that’s worth talking about.
What I got right
There are parts of my original article that I still stand behind.
Infrastructure matters. Reliability matters. Security matters. Performance matters. Support matters. And understanding what you’re actually buying matters.
If you’re running a dynamic application on an overloaded shared server, the fact that you’re saving a few dollars every month isn’t particularly useful when that infrastructure becomes the bottleneck for your business.
The same is true today.
What has changed is the number of alternatives available to us.
The web doesn’t always need a web server anymore
That sentence sounds a little strange.
Traditionally, somebody visits your website, their browser requests a page from a server, the application executes code, talks to a database, assembles the page, and sends the result back.
WordPress is a good example.
A request comes in. PHP runs. WordPress does its work. The database may be queried. Plugins may execute. A page is generated and eventually returned to the visitor.
There are layers of caching and optimization that can make that process extremely fast, but fundamentally there is an application running somewhere.
For many websites, we simply don’t need to do that anymore.
The Phillips WDC website is a good example.
There isn’t a WordPress installation behind this page. There isn’t a production MySQL database containing this article. There isn’t a publicly accessible CMS administration panel. There isn’t a PHP application generating this page every time you request it.
Instead, the site is built ahead of time.
The result is essentially a collection of finished files that can be distributed directly to visitors.
That changes the hosting equation considerably.
How this website works
The source for Phillips WDC lives in Git, and our repository is hosted on GitHub.
When changes are pushed to the repository, the website is built and deployed through Cloudflare. The finished site is then delivered through Cloudflare’s infrastructure.
The publishing workflow for this article is equally simple.
I can write the article locally on my computer, add it to the project, commit the change, and push it to GitHub.
The deployment happens automatically.
There is no CMS login required to publish the article.
That gives us something else I value: the content itself is version controlled alongside the software.
If something changes, we know what changed. If something breaks, we can see what changed. If we need to revert something, we have history. And the website can be reproduced from its source.
That’s a very different architecture from the WordPress sites I was talking about in the original article.
What happened to the $60 hosting bill?
For this particular website, it disappeared.
At our current scale, the infrastructure required to serve the Phillips WDC website falls within the services we’re already able to use without a meaningful hosting charge.
That doesn’t mean infrastructure suddenly became free.
Cloudflare operates an enormous global network. GitHub operates the systems storing and processing our repository. There are very real computers doing very real work somewhere.
The economics and architecture simply changed.
Instead of renting part of a traditional server whose job is to dynamically execute our website, we’re distributing pre-built assets using infrastructure designed specifically to do that efficiently.
For this use case, it’s a remarkably good fit.
There is also less to attack
I was very focused on security in the original article, and I still am.
But I would explain the issue differently today.
Security isn’t simply a question of whether expensive hosting is more secure than cheap hosting. That’s far too simplistic.
Architecture determines a significant part of your attack surface.
Consider a traditional WordPress installation. You may have WordPress itself, PHP, a database, an administrative interface, user accounts, themes, plugins, and a server environment that all need to be maintained.
That’s not an argument against WordPress.
WordPress is incredibly useful, and there are plenty of situations where I would still recommend it.
But every moving part of a system has to be maintained.
On this site, many of those moving parts simply don’t exist in production.
There is no WordPress admin panel to attack because there is no WordPress admin panel. There is no production WordPress database to compromise because there isn’t one. There aren’t twenty plugins waiting for someone to forget to update them because we don’t need them.
You still have security responsibilities. GitHub accounts need to be secured. Cloudflare needs to be secured. Dependencies need to be maintained. Deployment credentials need to be protected.
We haven’t eliminated security.
We’ve reduced the number of things we need to secure.
That’s an important distinction.
What I would correct
One of the benefits of leaving old writing online is being able to look back at your own thinking.
And there are things I would phrase differently today.
I implied that extremely inexpensive hosting probably meant the provider had fewer resources available for security and maintenance.
That’s not necessarily true.
Scale and modern cloud infrastructure changed that equation substantially. Some of the largest infrastructure companies in the world can provide tremendous amounts of capability at extremely low prices.
I also oversimplified the relationship between hosting performance and search rankings.
Performance matters. User experience matters. Nobody wants to wait for a website to load.
But saying that a competitor will simply outrank you because their hosting is faster reduces a very complicated search system to one variable.
That’s not how I would explain it today.
The more useful argument is much simpler:
Slow systems create bad experiences.
If somebody clicks an advertisement and leaves because your application takes too long to respond, it doesn’t really matter which search-ranking factor was responsible.
You’ve already lost the visitor.
Should everyone build a static website?
Absolutely not.
And this is probably the biggest difference between how I thought about infrastructure then and how I think about it now.
There isn’t one correct platform.
A marketing website and an ecommerce platform are different systems. An authenticated customer portal is different from a blog. An internal business application is different from a documentation site. A system processing payments has different requirements from a page describing your services.
Sometimes WordPress is the right answer.
Sometimes Shopify is the right answer.
Sometimes a custom application is the right answer.
Sometimes a serverless architecture is the right answer.
Sometimes you need dedicated infrastructure.
And sometimes a bunch of static files distributed around the world is all you actually needed in the first place.
Engineering is figuring out which one applies.
The lesson changed
When I wrote the original article, the lesson was essentially:
Don’t buy cheap hosting just because it’s cheap.
I don’t disagree with that.
But after years of building software, integrations, ecommerce systems, migrations, and infrastructure, I think there’s a better version of it:
Don’t start with the technology. Start with the problem.
Then choose the simplest architecture that solves it reliably.
Don’t pay $100 per month when $0 infrastructure solves the problem better.
And don’t force a $0 architecture onto a system that needs considerably more.
Price isn’t architecture.
Technology isn’t architecture.
Architecture is understanding what the system needs to do and making deliberate decisions about how the pieces should work together.
Apparently it just took me a few years — and a website with virtually no hosting bill — to find a better way to say it.