Running a Single-User Mastodon Instance

I’ve been running my own single-user Mastodon instance now for going on one week. While I’m clearly not an expert Mastodon Admin, I have run into a few things that I think are useful to jot down in case others are interested.

Using Mastodon from a Single-User Instance is a great way to own your own domain and take control of your online presence. However, as the sole user you’re also the admin responsible for making sure things are running smoothly (and of course, it’s not free). I want to go over a few items like how to host Mastodon on a subdomain but have your main domain in your username, moving between servers, and some settings for single-user instances.

Different Account and Server Domains

Firstly, you’ll notice that while my Mastodon username is @[email protected], the domain you’re reading this on is also calebhearth.com and is not a Mastodon instance. My personal website runs on Ruby on Rails and is currently doing the minimum effort to “reverse proxy” the requests that come in get information on my Mastodon instance and whether the “caleb” user exists on this instance.

The code I’m using for that, and possibly all you’re hear to find out, is:

config.middleware.insert(0, Rack::ReverseProxy) do
  reverse_proxy_options preserve_host: true
  reverse_proxy "/.well-known", ENV.fetch("MASTODON_HOST") + "/.well-known"
end

That code is enough to expose the required endpoints, but assuming that you’re hosting your account on a subdomain your account still won’t show up as the query for an account resource defined by ActivityPub includes the domain name, so the query that comes in looks something like:

https://calebhearth.com/.well-known/webfinger?resource=acct:[email protected]

and any resource that isn’t matched exactly will return an HTTP 404 Not Found response. The user that actually exists is [email protected] Mastodon can be configured to have usernames stored at a different domain than what it is hosted on by setting LOCAL_DOMAIN to something else. I’m actually hosting my instance on Masto.host, so instead of setting an ENV variable I followed these instructions and emailed their support address. They promptly switched it over for me.

IMPORTANT: this needs to be done before “federating” any content, so it needs to be set up before following anyone, redirecting from another instance, or anything else. I made this mistake and had to completely dump my previous instance and create a new one with a new subdomain because I imported my followings before changing LOCAL_DOMAIN.

Since your actual domain and the one you use for your account don’t match up, some places will render your username incorrectly. GitHub, for example, renders my account link https://pub.calebhearth.com/@caleb incorrectly as “@[email protected]” since they’re basically just changing how the string is structured. This pattern has showed up in one or two other places too. It’s possible to get the correct username/domain, and GitHub know about this, so I’m sure it’ll be taken care of at some point. My contact there says to please not ask them to fix it anymore. 🤣

I haven’t tried other apps since setting up this server, but Ivory required that I enter the subdomain when setting up my account in that app and displays my username incorrectly as above in the account picker, but it shows correctly everywhere else in the app.

Moving to a New Mastodon Server

This probably deserves its own post, as it’s not strictly related to single-user instances or hosting Mastodon on a different server than the username points to, but I’ll put it here anyhow. Mastodon provides account migration functionality that moves all of your followers to your new account (either on the same or a different server), and it allows you to import some of the data from your old server.

What it doesn’t do is allow migrating posts from your old server. That’s right, moving to a new server means leaving behind your old posts. This might be a blocker for you, or it might mean that if you think you’ll want to move to a new server you should do it as soon as possible.

Migrating your followers

Assuming that you have an existing Mastodon account that you’ve been using, you’ll want to keep your followers. To do this, create an account alias on your new server to your original account at Account→Account Settings→“Moving from a different account”. Then on your original server, at Account→Account Settings→“Move to a different account” you’ll enter your new account handle and old password. There’s some scary looking yellow-orange text on that page that you’ll want to read. It’s not clear to me whether this is a reversible operation, but as all of your followers will transparently stop following your old account and start following your new one without notifications or manual action on their part, I suspect it is not easy to back out of without going through this process in reverse.

Importing from your old account

You can export a number of things (again, notable not including posts) as CSV files from your old account. The ones I grabbed were Follows and Bookmarks, but if you’re using blocks or mutes you can export those as well on the “Import and export”→“Data export” page of your old server. On your new server, you can import these CSVs at “Import and export”→Import.

As soon as you import followers, they’ll begin to get notifications that you’ve followed them from your new account. This is the step that I incorrectly took before setting up LOCAL_DOMAIN above, so again please be sure that you’ve configured your instance with the username and domain you want to use before taking this step.

Request your archive

Mastodon won’t be able to import it (yet, at least), but you can still request an archive of your posts and uploaded media at “Import and export”→“Data export”. I did this and saved the file somewhere safe. If I had direct access to the Mastodon database, I could probably have written up a script to import my old posts, but Masto.host doesn’t offer this for good reason. Still, I wanted to have the backup just in case. Note that most servers have a limit on exporting your account to once per week, so do this once you’re done with your old account in case you make any more posts after that.

Settings for Single-User instances

Disable Sign-Ups

Definitionally, you don’t want anyone else joining your server. You can disable sign-ups at Administration→Server Settings→Registrations.

Allow Trends

Mastodon Admins are required to review trending hashtags and links before they’re displayed for all users. Your instance will send you emails telling you that there are new trends to review pretty frequently, and the need for this in the first place seems very strange. You can allow unreviewed trends at Administration→Server Settings→Discovery→
“Allow trends without prior review”. I ignored the scary “Not recommended” badge.

Branding

This is pretty optional, but you can change the branding of your instance so that instead of “Mastodon” the title of the page will be whatever you want it to. The settings are under Administration→Server Settings→Branding.

Relays

This is probably the biggest one. Mastodon won’t automatically fetch content from other servers except from accounts that are being followed by someone on your server. With only one user, that’s not a lot of content coming through. It makes following hashtags completely useless because aside from a few stragglers, no post that isn’t from (or boosted by) one of the accounts you’re following will show up. You also won’t see most responses to posts, direct links (such as https://pub.calebhearth.com/@[email protected], my previous account on another server) to usernames on your own instance likely won’t work and the account details won’t be automatically fetched, and likewise your own content won’t be federated to anyone who isn’t following you.

Relays are separate software from Mastodon that gather a bunch of posts, users, etc. and exchange them between servers. They help smaller servers discover content from outside accounts being directly followed. Adding Relays can be a balancing act because my little $6/mo instance won’t be able to keep up with the deluge from the bigger instances. The fediverse is incredibly inefficient as far as how data is shared.

Unfortunately, a lot of relays aren’t accepting new servers anymore, especially smaller ones, because they don’t really benefit from them as members and it’s expensive to exchange this data.

I found a recommended relay on a blog post somewhere. I’m happy to share the relay on an individual basis because I don’t want it to explode with new signups and overwhelm my own server or the others using it.

I am also using relay.fedi.buzz to pull in content from a few tags I’m interested in and a few Mastodon instances that I follow a bunch of folks on or that are relevant to my interests. I picked ruby.social, dice.camp, and hachyderm.io. It’s important that I didn’t pick any big instances, especially mastodon.social, because that would basically flood my server with the whole fediverse’s content which it couldn’t keep up with and which I’m not interested in. The same is probably true for popular tags. These relays, unlike “real” relays, don’t federate your content to the other instances, which is a difference worth knowing about.

You can set up relays at Administration→Relays. As far as I can tell, the form will accept any URL. You may need to wait for a while for the relay to approve your server. fedi.buzz relays auto-approved pretty quickly as did the other relay I’m using, but when I searched for popular relays and tried to add one it sat unapproved for about a day before I removed it.

Federation on Mastodon happens in background processes, so I kept an eye on the Sidekiq queue size and throughput after I’d set up the relays. It’s handling this amount of load pretty well for now. If you’re logged in as an admin, /sidekiq on your server provides a nice dashboard to monitor this.

Between the “real” relay and about half a dozen fedi.buzz relays enough to get a little slice of the fediverse beyond who I’m following. It also makes trending links and hashtags more meaningful.

Have you done this?

I’d love to hear any tips you have for running single-user instances if you end up doing this or already have. Are there useful settings I’m missing? Good relays you’d like to suggest?

It occurs to me that I could probably also set up a reverse proxy for the API endpoints and user page and that might fix the subdomain in account handle issue. I might try that at some point. I’ve mentioned before that I was working on a gem to connect my blog to the fediverse. I’m not sure yet whether this solution is good enough, but if I decide to keep going down that path then I could theoretically start to replace bits of functionality piecemeal if I set up proxies for everything. The user page, for example, could be a good place to start and would be able to match the styles of the rest of my site.

Anyway, let me know if you try this out and how it goes.