Hosting your own Mastodon server

Why Host Your Own Server

With Mastodon becoming more popular, I wanted to see what was invovled in creating my own server. I figured if it didn’t work out I could join one of the bigger servers later, either by creating a new profile, or by migrating the profile from my own server. There are a few reasons that I think make hosting your own server a good fit for you.

  • You want to have more control over your own content on the internet. While you may be able to move Mastodon servers, only your profile and followers go with you, NOT your posts
  • You want to experiment with the technology itself
  • You already have a bunch of people you want to follow and that want to follow you. Without this, it may be hard for your content to reach other federated timelines if people aren’t able to find you easily.
  • You want to host a community and are committed to maintaining and moderating your server.

If you are going to open up registrations, that last piece is important. While people can migrate out of your server should you decide not to maintain the server anymore, I think it’s important to be upfront with your intentions so your users aren’t suddenly scrambling to find somewhere else to go.

Still Want to Host a Server?

There are several options for hosting. There are managed products such as that you can just sign up and they manage the infrastruture for you. Something like gives you a little more control in that you own the machine itself (even if just in the cloud), but they manage installing the product on your machine. I don’t know much else about these services, but they are available if you are not interested in diving in the command line.

I’m interested in the code itself, but was also intimidated by the idea of installing from source. Luckily Digital Ocean had something to meet my needs.

My setup experience.

I opted to host on Digital Ocean after I found their 1 click app. If you’d like, you can use my referal code to get some Digital Ocean credits for yourself and for me if you don’t have an account yet. Once you have an account, go to the 1 click app page and you can create a droplet. When you do, make sure to click a droplet size that has at least 2GB of RAM. I was running into a lot of issues in with a 1GB droplet and am currently running at 80% in the 2GB droplet.

During that setup, make sure to choose to upload an SSH key. Here’s instructions on how to generate an SSH key. I find it’s more secure than using a password.

While that is setting up, we’ll need a few other things.

First I needed a domain name. I used to register mine, but feel free to use whatever provider you want. After getting my domain, I needed to configure the domain to in Digital Ocean. Here’s the link to the official documentation from Digital Ocean on how to setup your domain and DNS records.

I also needed an email provider. I tried to set up my your own email server on the droplet with the sendmail command, but my email were not being delivered to gmail. Whether it was an issue with my setup or gmail just blocking the emails, I’m not sure, but I eventually gave up. SendGrid has a free tier, which I think should be enough for a single user server. If you’re planning to open registrations you might want to shop around to find a provider that fits your budget. If you use SendGrid, follow the instructions in their documentation to set up an API Key.

With that all set up, let’s ssh into the droplet and install Mastodon. Here are instructions on connecting with SSH. Once you are connected, you’ll be greeted by the setup wizard and some prompts. Here’s what I put to configure my server. When things went wrong I was able to use disconnect from the droplet and reconnect to restart the wizard. The wizard appears to keep running until you succesfully complete it:

Welcome to the Mastodon first-time setup!
Domain name:
Do you want to store user-uploaded files on the cloud? No
SMTP server:
SMTP port: 587
SMTP username: apikey
SMTP password: <my_send_grid_api_key>
SMTP authentication: plain
SMTP OpenSSL verify mode: none
E-mail address to send e-mails "from": Sean <[email protected]>
Send a test e-mail with this configuration right now? no

I didn’t want to configure S3 or some other cloud host, so all user uploaded files will live on the droplet. It’s just me so I figured it’d be ok. The only other thing of note is that the SMTP username is literally apikey.

After completing those prompts I was able to create my admin account:

Great! Saving this configuration...
Booting up Mastodon...
It is time to create an admin account that you'll be able to use from the browser!
Username: squizzleflip
E-mail: [email protected]

Next I was given my initial password, and prompted to setup Let’s Encrypt for SSL

You can login with the password: YOUR-PASSWORD-WILL-BE-HERE
The web interface should be momentarily accessible via
Launching Let's Encrypt utility to obtain SSL certificate...
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): [email protected]

This failed a BUNCH of times - turns out when I set up the DNS recodrs I had a typo in my domain name. A frustrating error, but at least not a complicated one.

After that I had to update certificates:

sudo apt install ca-certificates

Lastly I needed to add localhost to the file /etc/hosts. And that was it! I was up and running!

Immediate Upgrades

I started posting on my instance and one of the first messages I got was “How did you manage upgrades?” to which I thought “Upgrades? I just installed it, what would I need to upgrade?” Turns out the Digital Ocean 1-click-app is set to Mastodon version 3.1.3, while the latest release is 3.5.3. COOL.

I connected to my droplet again and in another monitor and opened up the upgrade documentation. Fortunately you can update directly from 3.1.3 to the latest version, but the documentation does warn about making sure to follow any intermediary upgrade steps. For example, if version 3.2.1 has a unique upgrade setup, you’ll probably need to do that as well. I opened up all the releases and found I needed to do the following:

  • Run apt install shared-mime-info as root
  • Update ruby to 3.0.3 with RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install 3.0.3
  • Run bundle install
  • Run yarn install
  • Run SKIP_POST_DEPLOYMENT_MIGRATIONS=true RAILS_ENV=production bundle exec rails db:migrate
  • Run RAILS_ENV=production bundle exec rails assets:clobber assets:precompile
    • The docs don’t include the assets:clobber part, which caused me to run into this issue
  • Run systemctl restart mastodon-sidekiq
  • Run systemctl restart mastodon-web
  • Run RAILS_ENV=production bin/tootctl cache clear
  • Run RAILS_ENV=production bundle exec rails db:migrate
  • Run systemctl restart mastodon-sidekiq
  • Run systemctl restart mastodon-web

Once that was complete I was finally upgraded the latest version. Hopefully following those steps will make this a little more straightforward if you try this.

Lastly I set the server to single user mode by adding SINGLE_USER_MODE=true in the file /home/mastodon/live/.env.production. This disable registrations and points the domain directly to my profile.

What’s Next?

Things seem fairly stable right now, but I’m actually not sure what more work will be required. After a few months and some upgrades, I may decide to open up some limited registrations. If you want to try this yourself and have any questions, please feel free to tag in a post on @[email protected]! Good luck and happy tooting!

Across the Fediverse

The Fediverse

I’ll start with I kind of hate the term “fediverse”, but I do like the concept! If you’re not familiar with a federated network, Mastodon, or how this “bird site replacement” works, I’ll try to explain in as few words possible. A federated network is distributed amongst separate servers that communicate with each other using a common protocol or “language” (called ActivityPub if you want to dig into the details). So while your account lives in one server, because of the common language across servers, you are able to follow and reply to people on different servers.

Mastodon is one type of software that uses a shared language to create a Twitter-like replacement, and because of the federated network, all of these Mastodon servers are able to interact with each other. You could join any server and you’d be able to follow/reply to people on other servers fairly seemlessly. There are also other types of software like Pleroma or Pixelfed (which is like instagram), that also implement the same protocol, so you can even follow people using those platforms and vice versa!

You can join any server you want, and if you’re unsure I’d say just start with one of the bigs ones like The server you join doesn’t matter in the sense that you can communicate with people on other servers if you want, but it does matter in that it is where your posts will live and more importantly how the server is moderated.

Whoever is hosting a Mastodon server has complete control over that server. The admins can read any post on the server, including DMs. This is the case with something like Twitter, but the perception of trust can be different when it’s just a few hobbyists running a server as opposed to a giant corporation. Those admins also have control over which servers can interact with their server. For example, an admin on a Star Wars Mastodon server could block that servers interactions with a Star Trek server. So even though the Star Trek users are following the Star Wars users (and vice versa), the admin can decide that no Star Trek server posts will appear on their timeline.

Dunbar’s Number and a Better Online Experience

Having a distributed network means smaller user bases for each server. Instead of having to moderate the interactions and posts of millions of users on a single server, moderators only have to monitor the thousands or even just hundreds on their own server, while also having the ability to block communities in mass that don’t align with the values of theirs. Additionally, if an asshole suddenly becomes the owner of the instance you’re on, the fediverse’s portability allows you to leave a server and bring your followers with you to a server that you more align with.

The concept of many, small servers really appeals to me because I think it’s the best way to scale social networking that prioritizes safety because of the theory behind Dunbar’s Number. For those not familiar, Dunbar’s Number is the concept that an individual has a cognitive limit on the number of people they can maintain a stable social relationship, that number suggested to be around 150. To me, that means that I could potentially host a server of about 100 or so users and successfully priotize the safety of their interactions in my server. And because of the federated network, those users are not isolated to my server, they can freely interact with others in other servers. Again, if some asshat decides to buy his way into owning another server and it becomes a toxic hellscape, I can easily block that server’s posts from showing up in my server’s timeline.

If you’re familiar with Discord, which while not federated, you’ll see that it has a very similar feel. My online interactions on Discord are by far the least toxic and most meaningful in large part because of the small and separated nature of the servers.

Hosting My Own Instance

Currently I host a single user instance on I’m not sure if I will open registrations; I’m not sure what is going to be required of me to keep this thing running, what the costs will end up looking like, what moderating posts will be like, or even if there is interest to join. However, I am intrigued by the idea, especially if there were others that would be interested in helping admin and moderate the server. For now feel free to come follow me @[email protected] and if you would be interested please send me a message! I’m really excited about this technology and I hope more people start to jump on board. This feels like what the future of social networking should be!

A Decade of Code

Wax Nostalgic

Ten years ago, I walked into the Bluewolf office in NYC that overlooked Madison Square Park. I passed someone working in what looked like a phone booth, and I remember thinking, “wow that person must be super important, they have their own office!” After the tour and some brief intros, I was shuttled into that phone booth where my laptop awaited me. Turns out that person started the week before me and there just was no more desk space.

My first project was to help maintain a custom built CMS built using Ruby on Rails for some non-profit in the city. I don’t remember much of about it but I do remember breaking the staging environment, blocking the client from making any changes. Luckily they didn’t notice while my mentor and I panicked to figure out what we broke. Eventually that client contract ended and didn’t renew (for unrelated reasons, I assume), which meant I needed to start learning Salesforce development. 10 years and 6 jobs later, here I am. And if you’d indulge me for a bit, I’d like to share some lessons from along the way.

In No Particular Order, Lessons from a Decade of Code

  • Learning vim would probably make me very productive, or at least feel that way. I’ve given up every time I’ve tried
  • Everything is a form. It’s just inputs that you’re capturing for some other system to consume. This gives me existential dread sometimes
  • Rebuilding is almost never worth it, until it is
  • Being very responsive to every slack message will get you lots of praise. It will also quickly burn you out
  • I used to think being able to solve problems quickly during live meetings was a skill. It’s actually a a detriment that prevents other people from contributing that leads to poorly thought out solutions and should be discouraged
  • The value of meeting plummets after adding more than 3 people. I promise you it should just be an email
  • No new feature cycle, from ideation to delivery, should be less than a day. I don’t care how small that change is, it needs to be prioritized like everything else or else you’ll constantly be drowning in “quick changes”
  • Processes not only protect the product, but they also protect you. However they should also work for you, not the other way around
  • A sustainable pace is critical for any role that you want to last for more than 2 years
  • Burnout takes months to recover from. It’s not something you can just take a long weekend to fix, especially if you don’t address the cause when you get back
  • Don’t derive your value or your passion from work. It will only hurt you
  • Working from home is the best and I would NEVER work in an office again if I had the choice
  • Version control is the single most important piece of technology if you’re writing code. It’s the bare minimum and I refuse to work in any environment that doesn’t have it
  • Design patterns should serve as inspiration, not as rules to be followed dogmatically
  • The agile manifesto itself is really good - it’s a focus on building a process that works for those involved, favoring a frequent feedback loop. If you ever say “that’s not Agile”, you’re missing the point
  • Documentation doesn’t get enough love. Code can’t document itself - the code can only do what’s written, it’s bad at showing intent
  • You will NEVER beat Excel. You should embrace it and integrate with a spreadsheet instead
  • You’ll generally make more money switching jobs than a promotion
  • Always ask for more than what you’re making. If a recruiter asks what you’re looking, add 20% over what your currently making. If they ask how much you’re making, lie
  • Transactional data should be separate from analytics data. Specifically, putting analytics data on your sObjects like Account is an anti-pattern
  • Capture events that happened, not timestamps that imply something. FIGHT ME.
  • I hate pair programming and I think it should be ok if you never want to do it
  • Favor async over synchronous collaboration
  • Giving people the chance to hit that flow state is the cheapest way to make your employees happy
  • Invest in good tools (chairs, monitors, desk, etc). You’re using them for at least a third of your day
  • You don’t need a side project. If you have one, don’t hesitate to work on it during the work week. You’re getting your work done right? So no one should care and it counts as professional development
  • Take the time to experiment with technology. On company time.
  • Keep your personal projects off company assets. I don’t know how enforceable those technology tranfers are and I don’t want to find out
  • Recognize the signs of burnout - no one is going to do it for you, you have to advocate for yourself
  • Getting really good at one thing can be very lucrative as opposed to chasing the latest technologies
  • Max out company matching on your retirement account - it’s free money
  • You don’t have to be passionate about your job to be good at it
  • Your job is not your family. You can (and probably will) develop friendships on a personal level with your coworkers naturally, but the idea that your company can be family is a lie
  • You will have trash managers. Leave if you can
  • You will have incredible managers who actually do feel family. Thank them often and let them know
  • Just because you’re good at your job doesn’t mean you’d be good at managing others doing that job, or that you’d even like management
  • Think often what you like about a job. Lean into that. You don’t have to love your job, but maximizing the parts that bring you joy helps
  • If software development didn’t pay like it does, I absolutely would do something else, and that’s ok if you feel that way
  • Forgive those that came before you. You don’t know what time pressures, uncontrollable circumstances, etc. that led to the state of the codebase. Don’t get angry, just take this into account when you pad your estimates
  • Estimates can be pretty arbitrary, but they become less so the more you do them, and they are very important when it comes to planning
  • Don’t be the only person that can do your job, there should always be at least two so that you can go on vacation
  • Be kind to each other. Avoid toxic interactions and embrace those that bring you joy. This is really hard
  • Know which battles to fight. When you stand your ground it’ll be really apparent how much it matters
  • You are worth it. You are worth that promotion, that raise, that time off. You deserve to be in that job, you know what you are doing

I could probably do this all day, but this is enough for now. Here’s to 10 more years of code! Thank you everyone that helped get me here because I certaintly did not do it alone. And if you’re starting your journey, I hope I can help you as well.