Goodbye, DreamHost

I’ve been a DreamHost customer ever since I switched from hosted solutions to managing my own website. Back then, I was searching for a web hosting that would allow me to host a Known instance with as little hassle as possible, and DreamHost was one of the first options IndieWeb Wiki listed. I gave it a try and fell in love immediately.

DreamHost was great. Very easy to set up, with clean and comfortable to use administrative panel, seamless SSH access, and everything you’d need for a little private website available and easily accessible. PHP worked seamlessly, setting up a MySQL database was a piece of cake, and I could even set up a cron job to make regular backups (and have my home server fetch those via rsnapshot).

Once you start managing your own site, you start thinking about setting up services for yourself. I’ve set up subdomains for FreshRSS and Baïkal, added a Debian repository for my little pet project, and everything worked so smoothly that I even moved my primary email to DreamHost. Then I moved my blog to Hugo and setting up git hooks and scripts for site rebuilding and webmention sending was even less of a hassle than setting up Known back in the day. If I ever had any question, support was there to help, nice and knowledgeable, if not immediate. DreamHost was indeed living up to its name!

That is, until last August when I found myself unable to send any email. DreamHost is outsourcing its mail filtering to MailChannels, including outgoing mail, and it may be a sane thing to do, considering that they are primarily a web hoster; if you host websites that can generate mail, it is reasonable to take precautions and filter outgoing mail so as not no end up in the blacklists all over the Net. However, they took filtering a little bit too far: my outgoing mail (sent from a mail client that legitimately authenticated itself to DreamHost’s SMTP server) got returned because MailChannels didn’t like the IP I was sending it from. I was on a hotel WiFi, so the IP was likely abused from time to time, but providing my password to the SMTP server should have told DreamHost I was a legitimate sender, shouldn’t it?

It took a couple of days for support to comprehend the situation and finally tell me that they thought the system was working as intended and that I could use webmail if I ever found myself in such a situation again. They failed to explain to me why it was not OK to use a mail client if it was OK to use webmail from the same IP with the same credentials, so I started looking for a proper email hoster that had sane filtering policies. I was still perfectly satisfied with DreamHost as a website hoster, so while the mail hosting experience was a major disappointment, I still was comfortable hosting my website with them. I did move my email elsewhere, of course, after the second occasion, when MailChannels didn’t like the dynamic IP my cellular carrier issued…

But people that make stupid blocking policies reached DreamHost’s web hosting department, too, so last week I came back from my vacation and found that my office PC couldn’t sync my calendar. A quick investigation showed that the hospital’s IT department relaxed outgoing firewall rules earlier this year, and some malware on the internal network made sure the hospital’s IP ended up in one of the FireHOL’s blacklist as a source of excessive port-scanning. DreamHost happily blackholed all the traffic coming to the shared webserver from that IP! I contacted the support, and they confirmed that this indeed was the “desired” behaviour: the IP that did the port-scanning was, according to them, “unsafe” and could not be trusted to access the server in any way.

I was speechless. I mean, I would understand if they blocked SSH access, for example. I would understand if they blocked the access to the admin panel (which they didn’t, funnily). But the main reason people pay them money is so that they make sure people’s websites are accessible, and that’s what they decided to block the access to? Portscanning activities usually originate from public WiFi networks, ISP’s dynamic IPs, Internet cafés and such — does this mean that my website is likely unreachable for users in these places?! Yes, — the support answered, — and that’s for your own good!

Well, dear DreamHost, I paid you to make my website available, not to block access to it. I’m not paying you another dime, and I’m not advising you to another friend, and when your next security expert tells you that a good way to improve security is to take the server completely offline (which is true, by the way) my website will not be affected. I’ve moved it already.

It was, by the way, not easy to find an alternative. I actually failed in this search — looks like the DreamHost experience gave me too high a bar. I looked at over twenty hosting companies and tried several of them — if you want something beyond WordPress, you’re in for a disappointment. Lack of SSH access, nginx for a web server (good luck setting up 410s!), artificial restrictions on everything possible, CentOS instead of an operating system (their libraries are so old you can’t really run anything but a shell script), ridiculous terms of service¹, and every other thing done backwards — that’s the web hosting market in 2021.

I ended up using a VPS. Installing and configuring a LAMP stack, certbot, and a firewall is not exactly rocket science, and the added admin tax shouldn’t be unbearable, considering I have to take care of my home server anyway. But now that I have successfully set it all up, and migrated everything from DreamHost without a single hiccup, I feel much more confident. If DreamHost goes out of business with their ridiculous access policies, and some of their security experts end up hired by my current hoster, I know that I can move everything elsewhere in a couple of hours.

And I enjoy this freedom.