Comments on Shared Unix Hosting vs. the Cloud

16 min read Original article ↗

| blog | oils.pub

2025-02-06

This is a follow-up to Comments on Scripting, CGI, and FastCGI, from June (lobste.rs comments).

I mentioned problems with Dreamhost, and described how the CGI and FastCGI protocols are dying.

I gave up on FastCGI, but I'm not giving up on lightweight scripting for the web! That's one reason I'm still using shared hosting.

I just finished migrating our new oils.pub domain from Dreamhost to another shared host, Mythic Beasts. This post has comments on my experiences, and other services I looked at.

Toward the end, I contrast two styles of server-side computing:

Style User Interface Programmability Dev Model
Shared Unix Hosting Unix Shell, text, protocols like ssh git rsync Scripting Personal
Cloud Services Proprietary Data and Interfaces SDKs, Pyramids of Code Big Teams Supported by Many Customers

What is Shared Hosting?

I've been using and recommending shared hosting for many years, but I've noticed that programmers who "grew up" with the cloud don't have a mental model of it.

They don't think of Unix as a multi-user system; they think of it as a component you put inside virtual machines or containers!

For example, I wrote this comment on a 2022 article about serving static files:

What's wrong with shared hosting? ...

I think the industry (or part of a generation of programmers) somehow collectively forgot that it exists

Shared hosting is a Linux box with a web server that someone ELSE manages. You get an SSH login, and you can use git and rsync.

It's associated with PHP hosting, but it is perfect for static sites.

...

FWIW I also have a Linux VPS with nginx and a HTTPS certificate, but it's a pain. I much prefer using shared hosting for things I want to be reliable

Does It Still Make Sense?

I've been making this argument for awhile, but I should add some caveats. In theory, shared hosting still makes sense:

But in practice, it seems that decent quality shared hosting no longer a commodity.

PHP hosting is still a commodity, but Unix hosting is not.

My comment above may have over-generalized from Dreamhost to all shared hosting services. I've used Dreamhost since 2009 (15 years!), and they had competent Unix system administration, and fast hardware and networks.

But I now suspect the Unix part was accidental — it's a layer that runs PHP, not something that most customers care about.

Shared hosting did acquire a reputation for a "race to the bottom" in the early 2000's. In the 2010's, many shared hosting companies were acquired and "optimized", or shut down.

So there don't appear to be as many alternatives to Dreamhost as I thought.

Background: Why We Migrated

In June, I mentioned that Dreamhost moved my account to a new server, and it no longer reliably supports FastCGI.

It has a new cgroups configuration that interferes with FastCGI processes. Moreover, the server would also kill my SSH processes, so I couldn't debug the problem!

Support didn't tell me what the problem was, but I found a way to drastically reduce the load on the site.

There were many spammy crawlers (including AI crawlers) hitting dynamic pages, so I disallowed them via robots.txt. That made the server more responsive, and I thought it would fix the stability problems.

But problems persisted, despite having almost zero traffic to dynamic pages. I mentioned that last month: Appendix: Dreamhost SSH Has Become Unreliable.

The last straw was that log rotation and compression on oils.pub didn't work, even though it works on my other domains.

I contacted support, and they said they fixed it.

A week later, it broke again. Then they said that it may not be looked at for several months. That is, Won't Fix.

I Don't Blame Dreamhost

This sounds like a big complaint, but I'm not too surprised. I think shared hosts make money from PHP hosting, not Unix hosting. I imagine that:

What's less forgivable is the continued SSH flakiness, and the lack of support on that issue. I think PHP deployment still relies on SSH/rsync, but I'm not sure.

Anyway, I had a great service from Dreamhost for 15 years, so I'm not too disappointed. I think that's the longest subscription I've ever had, so you could argue they were the most reliable company.

It took some time to migrate oils.pub, but in the end, it was good for the site. I cleaned up some tech debt accumulated over 8 years.

Interlude: Should I Use a Cloud Service?

I spent a lot of time faffing with the migration:

  1. Setting up subdomains for little apps
  2. Tweaking Apache web server config files
  3. Re-wrapping and re-deploying Python WSGI apps
  4. Accounting for differences in access.log
  5. Writing deployment scripts, which account for different dir structures

It definitely crossed my mind that I'm old and should use something more modern :-)

After all, I recently recommended Github Pages to a contributor, for a purely static site, and that turned out well.

But then I looked at what other people have used for hosting, like:

And I don't see an obvious, stable thing I'm missing. I see some of the long evolution I've gone through:

  1. CGI
  2. mod_wsgi (a shared library in Apache)
  3. Google App Engine
  4. Plain HTTP with gunicorn, on a VPS
  5. FastCGI, on shared hosting
  6. uwsgi (discussed below)

My conclusion is that web and cloud hosting is not very stable, at least if you care whether things work in 5 or 10 years.

Partly, this is a Python problem. PHP definitely does better. (I even wrote PHP for the first time in 2021 to understand this space better. I liked it, but I'm more likely to use Python and Go in the future.)

So it's not just me? I don't think there are that many great options.

The end of this this post will talk more about cloud services, but let's talk about shared hosting first. If you're not familiar with it, my experiences might help you understand what it is.

You get a non-root Unix account with a web server, but you don't have to maintain and patch it. The hosting provider maintains the server for dozens or hundreds of customers.

Mythic Beasts - Real Unix Hosting

This site now runs on Mythic Beasts, basically because they are a Unix host, not just a PHP host.

The only downside I've found is that the log rotation scheme is not friendly for backups and offline analysis. It would be nicer if the files were immutably named like access.log.2025-02-04.gz, rather than an ever-rotating access.log.2.gz.

I worked around this with a shell script, of course. (We continue to avoid burdening your computer with third party JavaScript analytics.)

Other Hosts

Here are some impressions of other shared hosts I tried. These are just my opinions; I'm not trying to do a comprehensive "review" of different services.

A2Hosting - How Bad Can It Be?

I somehow got the impression that this company had fast hardware and networks, like Dreamhost.

But I underestimated how bad the control panel software could be. I don't remember everything that happened, but I had a hard time from the start, setting up a simple subdomain. This was easy on all the other hosts.

It reminded me that shared hosting was a "race to the bottom". I quickly cancelled and abandoned this account, wasting $30 or so.

OpalStack - Promising

OpalStack is a unique shared host that also supports Python, not just PHP. It does so via uWSGI, rather than plain HTTP servers:

But I find the uwsgi architecture odd, which I mentioned in June:

I just looked at the official docs — The uwsgi Protocol — and this confirms that it's a truly bizarre protocol. It contains affordances for every language it supports:

  1. Standard PSGI request (Perl)
  1. Standard LUA/WSAPI request
  1. Standard RACK request (Ruby)
  1. Standard JVM request for The JWSGI interface and The Clojure/Ring JVM request handler
  1. Standard Running CGI script

...

  1. Standard Running PHP scripts
  1. Standard The Mono ASP.NET plugin request

...

Now what if it needs to support Go or Rust?

The whole point of protocols and interchange formats is that they should be language-independent. They can be re-implemented many times.

A standard should be an narrow waist, aka an M x N waist. But uWSGI is a tightly-coupled architecture and large protocol. (Docker also suffers from related problems.)

This isn't really a knock on OpalStack, because many people seem to recommend uWSGI. I guess it's what nginx supports.

But for now, I'll stick to plain HTTP servers.

Nonetheless, I still have the OpalStack account, and will continue using it.

NearlyFreeSpeech - FreeBSD

NearlyFreeSpeech usually comes up when I mentioned shared hosting. I used it briefly a few years ago.

I was surprised that it was based on FreeBSD! I use Linux on my local machines, and I prefer my remote machines to be the same.

It also has cloud-like usage-based pricing, which I found complex. A fixed monthly fee seems simpler.

But overall, it seems like a great service, and I hope they continue to grow.

Others

Back in June, a reader mentioned UberSpace, a German host which looks nice:

I haven't used it though.

Not That Many Options

I also glanced at the docs of all the shared hosts I could find, like Hostinger, HostGator, IONOS, etc. But again, I think they're better thought of as PHP hosts, not Unix hosts.

They don't really support Python, and definitely don't support persistent HTTP / FastCGI servers.

So I'm glad I found Mythic Beasts and OpalStack. But overall, the options seem thin. Unix hosting is no longer a commodity.

The situation reminds me a bit of this comment:

Ex Amazon here. Most grumpy system engineers did not disappear: we got hired by Google/Amazon/etc to build large-scale infrastructure... and sometimes sell it back to you as a service.

That is, I think it's hard for hosting companies to find skilled Unix administrators. The cloud has made those skills desirable, and "scalable".

My memory is that SREs at Google (site reliability engineers) started to earn as much or more than than SWEs (software engineers) around 2010 or so. And those were the early days of the cloud, which has grown a lot in 15 years.

What's Wrong With Cloud Hosting?

Now let's return to the question of whether cloud services are a good alternative to shared hosting.

Practically speaking, I see two problems with most cloud services:

  1. Lack of open protocols, which implies a tight coupling of the app and the platform.
  2. Lack of stability, over say a 10 year period, mostly due to the business model.
    • Concretely, the Oils blog is now 8 years old, and people still read posts from years ago. The Lindy Effect suggests that I should pick hosting services that were around before Oils! Otherwise, they might be gone before we're gone.

How does this compare with shared hosting?

Let me elaborate a bit on the first point.

Lack of Protocols

Most cloud services seem to suffer from the same problem as uWSGI: they have special support for each language.

This applies to "PaaS" aka "serverless" products, discussed in the June post. It would be nice if we had a modern version of CGI and FastCGI. They are protocols that can be implemented in any language.

Honest question: if you're using a newer language Zig or YSH, how do you plug it into these cloud services?

When I look at these pages, I see a lot of "canned" solutions, but no protocols.

Heroku seems better, and I've circulated their Twelve Factor App page:

Have a clean contract with the underlying operating system, offering maximum portability between execution environments;

Unfortunately, Heroku was swallowed by Salesforce before it reached its full potential. I suspect that they've since lost some software development capacity, and that's why they're moving towards Kubernetes and Docker:

A Hosting Platform Should Be Specified Like an Operating System

Wouldn't it be silly if Unix came with a canned set of programming languages? What if you had to modify the kernel to support a new one?

Moreover, imagine that each Unix machine had incompatible syscalls.

That's essentially the current situation with the cloud.

The mechanisms that make Unix language-independent aren't hard:

CGI is also a very simple concept.

So I think it's time to think of the cloud as a real operating system, not a bunch of unstable services. I may return to these ideas later.

Philosophy / Quotes

Here are a couple quotes related to lightweight scripting. My first impressions of web3 (2022) says:

We should try to reduce the burden of building software.

At this point, software projects require an enormous amount of human effort. Even relatively simple apps require a group of people to sit in front of a computer for eight hours a day, every day, forever ...

As long as software requires such concerted energy and so much highly specialized human focus, I think it will have the tendency to serve the interests of the people sitting in that room every day rather than what we may consider our broader goals.

I think changing our relationship to technology will probably require making software easier to create, but in my lifetime I’ve seen the opposite come to pass.

Unfortunately, I think distributed systems have a tendency to exacerbate this trend by making things more complicated and more difficult, not less complicated and less difficult.

So if we want to avoid software complexity, and huge teams of cloud engineers, then we might start with commodity hardware and Unix kernels. They've both gotten faster and more capable in the last 20 years.

The Unix shell is also a good place to start!

My comment on the essence of Unix is also relevant:

I generally agree with this article in that PROGRAMMABILITY is the core of Unix, and it is why I've been working on https://oils.pub/ for many years

However I think the counterpoint is maybe a programming analog of Doctorow's "Civil War on General Purpose Computing"

...

The Unix/shell version of that is that valuable and non-trivial logic/knowledge will be hidden in cloud services, often behind a YAML interface.

And your job is now to LLM the YAML that approximates what you want to do

(I don't want to use LLMs like that, but I also think that we're learning good ways to use them.)

Conclusion

I just want write some scripts and SSH to a beefy Unix box :-) I don't want to maintain kernels, web servers, or SSL certificates.

I'm not sure I'll recommend shared hosting in general anymore, because it isn't a commodity.

But I'm glad that I found more than one high quality service. Draw your own conclusions, and let me know if I missed anything!

Appendix: Some Cloud Services

I'll mention a few services here, so readers don't think I'm not aware of them.

I should also mention that I worked at Google for over a decade, while the cloud was "being formed", so I have a sense of the coding and architecture horrors that lie in these platforms. (For example, in the Kubernetes service, 3 and a half control planes stack on top of each other.)

Static sites / CDN:

I should also mention Sourcehut Pages. We use Sourcehut, and I like what they're doing, so I should try it. Though my current problem is not just static content. (Since Sourcehut is open source, it would be cool to add dynamic page hosting to it!)

Apps / Platform as a Service:

I think many of these companies don't meet my "Lindy Effect" criteria. Being old has two advantages: platform stability, and business model stability (compared to being VC-funded).

I think of "serverless" as a rebrand of "PaaS". They seem to suffer from the "SDK problem":

Cloud hardware / CDNs:

IaaS:

Again, let me know if you've had good experiences with scripting in the cloud! I host little apps to resize images, scrape web content, my personal wiki, and a few cron jobs.