While making sure this very site (giovanni.pw) was properly configured on Canopy Host — real domain, real SSL, not just the platform’s auto-generated internal address — I removed the leftover internal .apps.canopy.pm domain that Dokku generates by default. Routine cleanup. Except https://giovanni.pw/ immediately stopped serving: TLS handshake, unrecognized name.

The cause was a real bug, not a fluke: dokku letsencrypt:disable/:enable operate per-app, not per-domain — one certificate covers every vhost on the app. The domain-removal route called ssl().disable() unconditionally, before removing any domain, on the assumption that disabling was scoped to the one domain being deleted. It wasn’t. Removing the harmless internal domain nuked HTTPS for the real one sitting right next to it.

The recovery was immediate — re-running the SSL-enable step restored the cert in seconds. But the more useful part was what came after: fixing the actual bug rather than just moving on once the site was back up. The route now checks whether any other domain still needs SSL before touching the app-wide setting at all; it only tears down certificates entirely when the domain being removed is the last one left. Two tests now cover exactly this — remove-with-a-sibling-domain-remaining, and remove-as-the-last-domain — so the distinction can’t quietly regress again.

Nothing about this was exotic. It was a five-minute mistake, caught by immediately verifying the change against the live site instead of assuming success, then turned into a permanent fix with real test coverage rather than a one-off manual patch. That loop — change, verify against reality, and if something’s wrong, fix the actual cause instead of just the symptom — is most of what reliability work actually is.