Stop using Dreamhost

[lgarron]

With all due respect to their stability over the last decade, Dreamhost's DNS and HTTPS functionality is — let me put this politely — garbage. Their support is fairly responsive, but doesn't actually fix the fundamental issues that have taken our sites offline about 10 times over the past year, without any permanent workarounds I can use: https://twitter.com/lgarron/status/1592018042959323137

There are also several other issues, such as:

• Each deployed site can only be accessed by one user — there is no practical way to do access control, despite "unlimited" users and storage.
  • In particular, it's impossible to give a user read-only access, which means that we can't set up a user to access the server for backups without also giving it write access to everything.
• They only do ACME validation using /.well-known, which affects the hosted files on disk. This feels like an amateur implementation (they control our DNS, and could easily be using that instead!), and has caused troubles for me in the past.
• I have yet to figure out how to set up proper secure email on Dreamhost. One of the I have set up is being spoofed by spammers to send mail to itself. I need something which properly implements DKIM and MTA-STS.
• Their panel is slow, and has issues with doing multiple things in parallel (such as opening a bunch of sites in different tabs to change a config in all of them at once… because you have to do it slowly and manually for each individual site).
• Dreamhost is on the trailing edge of security standards, across the board. They implemented Let's Encrypt certs very late (and badly, as documented above), and dreamhost.com doesn't even use HSTS. Their email interface was unencrypted for the longest time.

This is blocked on:

• Use OctoDNS to place DNS config in source control #1

As an alternative, we need something which can provide the following features:

• Host several dozen domains, without manual or time-consuming config per site.
• Good static hosting for most domains, ideally with a low-fuss way to set up node-based servers on other domains. I'm okay with leaving PHP in the dust, so that our org can go all-in on JS (which is much more welcoming to new contributors and potential maintainers).
• 10 seconds to deploy. I know this sounds fussy, but given the realities of service workers, caching, and CDNs (and limited volunteer time), we often need to test or confirm things in production, sometimes while live debugging with a collaborator or user. We've made great gains in bringing down compile times for all our project, and I don't want it to lost it all to a slower deploy¹.

https://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/

10 Seconds

After 1 second, users get impatient and notice that they're waiting for a slow computer to respond. The longer the wait, the more this impatience grows; after about 10 seconds, the average attention span is maxed out. At that point, the user's mind starts wandering and doesn't retain enough information in short-term memory to easily resume the interaction once the computer finally loads the next screen.

> cd ~/Code/git/github.com/cubing/cubing.js
> time make clean deploy-twizzle
[...]
Executed in    9.43 secs      fish           external
[...]

Footnotes

1. You could argue that it shouldn't be "too easy" to deploy, because that could make it easy to break things. But I would argue that this should be tackled by other means: tests, deploy checks, access controls, staging environments, automated status checks, etc. ↩