Despite being aware of Mastodon and following its development since its introduction back in 2015, I never really spent any meaningful time with it. Along with many others, I was motivated to change this as for so many reasons including but certainly not limited to Elon Musk’s capricious “leadership” of Twitter.
I initially signed up with an account on Mastodon.social, the “first-party” instance that’s run by the service’s founder. After poking around a bit, I decided I’d prefer to run my own instance that maybe some friends and family could share if they were interested. After reading over the requirements and officially-supported architectures for the image, and looking into options for self-hosting either on my home lab or in some IaaS provider, I decided that this was a case where I’d prefer to have a host. If friends or family wanted to use it, I didn’t want to be on the hook for keeping it running during or after power outages, etc. Looking for servers and primary administration outside of the US, I found Cloudplane. Reasonably priced for a “small” instance, which is probably all I need.
Cloudplane makes it fairly easy, although the documentation is sparse. During their signup, they seemed to indicate that the name server the customer uses must support root-level CNAMEs or aliases, and they seemed to recommend Cloudfront. After a little more discovery, I learned that the root-level CNAME/alias requirement only applies if you intend for the root of your domain to point to the Cloudplane-hosted Mastodon instance. In my case, where I intended to use mastodon.alvani.me as the name of the domain, but use Mastodon’s local_domain and web_domain features to make handles as @alvani.me/@jehanalvani.com
Thus, once the new Cloudplane instance was deployed, I added alvani.me as the local_domain, and mastodon.alvani.me as the Cloudplane-labeled “Custom Domain”. Cloudplane informs you of the DNS records to configure - in my case just a CNAME.
[Update] Since I’m using a subdomain and Cloudplane’s proxy for seucrity features, I also had to set up a root-domain txt record. The same record displayed if I typed “example.com” into the web domain field.
There’s one more step to take care of: Cloudflare defaults to unencrypted backend connections, and Cloudplane requires encryption. I solved this by creating a Cloudflare configuration rule to capture all requests for the host mastodon.alvani.me, and setting the SSL encryption mode to Full. I also overrode the defaults for my account to SSL encryptions mode - Full (Strict).
The rule expression in my case was:
(http.host eq “mastodon.alvani.me”)
Then scroll down to the “SSL (optional)” section and choose “Full”.
Once configured in Cloudflare and propagated, I could access my hosted instance at the name I preferred.
The last step is enabling the well-known redirect per Mastodon’s documentation:
To install Mastodon on mastodon.example.com in such a way it can serve @[email protected], set LOCAL_DOMAIN to example.com and WEB_DOMAIN to mastodon.example.com. This also requires additional configuration on the server hosting example.com to redirect or proxy requests to https://example.com/.well-known/webfinger to https://mastodon.example.com/.well-known/webfinger. For instance, with nginx, the configuration could look like the following:
location /.well-known/webfinger {
add_header Access-Control-Allow-Origin ‘*’;
return 301 https://mastodon.example.com$request_uri;
}
In Cloudflare, this is accomplished with a Redirect rule. Note that the check mark at the bottom to preserve query parameters is checked. That’s important.
