Blog

I decided I didn’t want to run my own Mastodon instance anymore, so I needed to learn how to remove a Mastodon instance on YunoHost.

While I do think everyone who uses social media should have a presence on the Fediverse, that doesn’t mean everyone should run their own instance.

Managing my own host came with all sorts of problems and responsibilities: dealing with updates, worrying about whether other instances will defederate from me if I don’t defederate from certain other instances, and Mastodon eating up the storage and memory on a self-hosted server in my home office/studio.

I ran a single-user instance so I didn’t even have to worry about moderation and generally being “on call” for my own corner of the Fediverse…which one would have to do if they open their server to other users (even if it’s only their friends).

It was fun and educational, but I reached a point where I wanted to step back and let someone else handle the admin side, so I went back to Hackers.Town for my main account.

This post is a walkthrough of how I shut down my Mastodon instance “properly” on a YunoHost box: deleting users, enabling Mastodon’s self‑destruct mode, and uninstalling the app on YunoHost.

Why I shut down my instance

When you run your own Mastodon instance, you’re not just a user, you’re an admin. That means:

• Keeping software and dependencies up to date.
• Handling moderation decisions, including defederation from bad actors.
• Being responsible for data: other people’s posts and profiles if you let anyone sign up.
• Debugging weird Ruby, PostgreSQL, and Redis issues at the worst possible time.

I realized I’d rather invest that energy into building other stuff, instead of babysitting my own server.

So I decided to shut my instance down in a way that:

1. Cleaned up local accounts.
2. Sent delete events out to the rest of the fediverse.
3. Removed the app from my YunoHost server.

What “responsible shutdown” really means in the fediverse

There’s no perfect “delete everything everywhere” button in a federated network. Each server holds its own copy of data, and some may not honor delete requests. But a responsible shutdown, in my opinion, looks like this:

• Delete local accounts via tootctl so they send proper delete activities.
• Enable self‑destruct so Mastodon broadcasts that the instance is going away.
• Uninstall the software and stop serving the domain, so nothing new is happening.

I got what I wanted from running my own instance: I learned a lot about Mastodon, YunoHost, Ruby, and the realities of being a single-user Fediverse admin.

Now I get to enjoy being “just” a user on Hackers.Town again without worrying that my instance is down right when someone is looking for a post I made earlier.

If you’re in the same boat, tired of admin life but wanting to shut things down cleanly, these steps should get you there.

Step-By-Step Guide To Shutting Down A Mastodon Instance (on YunoHost)

Step 1: SSH into the YunoHost server

First, I SSH into my home server as the admin user:

bash
ssh dingusadmin@garrett.life

Once I am in, I switch to root:

bash
sudo -i

My prompt changes to:

bash
root@dingusadmin:~#

My YunoHost uses dingusadmin as the primary SSH user; sudo -i gives you a root shell for the system‑level work.

Step 2: Find the Mastodon app directory

On YunoHost, the Mastodon app lives in /var/www/mastodon/live (this is where bin/tootctl and the Rails app live).

I go to there:

bash
cd /var/www/mastodon/live
pwd
ls

I see a typical Mastodon tree: app, bin, config, db, Gemfile, package.json, etc. That confirms I am in the right place.

Step 3: Fixing the Ruby mismatch so tootctl works

When I tried to run tootctl directly:

bash
bin/tootctl --help

I got:

text
rbenv: version `3.4.7' is not installed (set by /var/www/mastodon/live/.ruby-version)

The .ruby-version file said 3.4.7, but rbenv didn’t have that version installed. I checked what versions were installed:

bash
ls /opt/rbenv/versions

I saw:

text
3.4  3.4.5  glitchsoc  mastodon

So 3.4.5 existed, but 3.4.7 didn’t.

Instead of going down the rabbit hole of compiling another Ruby, I pointed Mastodon at the version that was already there.

I backed up .ruby-version and changed it:

bash
cd /var/www/mastodon/live
cp .ruby-version .ruby-version.bak
echo 3.4.5 > .ruby-version

Then I tested tootctl again, this time with a PATH that uses the Mastodon rbenv setup:

bash
sudo -u mastodon RAILS_ENV=production \
  PATH=/opt/rbenv/versions/mastodon/bin:/opt/rbenv/bin:/opt/rbenv/shims:$PATH \
  bin/tootctl --help

This time it works and prints the list of available commands, including accounts and self-destruct.

Step 4: Listing local accounts

Before deleting anything, I want to see exactly which local accounts exist. There isn’t a tootctl accounts list, so I use the Rails console.

From /var/www/mastodon/live:

bash
sudo -u mastodon RAILS_ENV=production \
  PATH=/opt/rbenv/versions/mastodon/bin:/opt/rbenv/bin:/opt/rbenv/shims:$PATH \
  bin/rails c

In the Rails console (irb(main):001:0>), I run:

ruby
Account.local.pluck(:username, :domain)

The output looks like:

ruby
[["mastodon.internal", nil], ["garrett", nil]]

So I have two local accounts: mastodon.internal (the internal system account) and my own account garrett.

Don’t forget to exit the console:

ruby
exit

Step 5: Deleting local accounts with tootctl

With the usernames in hand, I can delete them one by one using tootctl accounts delete.

Still in /var/www/mastodon/live:

bash
sudo -u mastodon RAILS_ENV=production \
  PATH=/opt/rbenv/versions/mastodon/bin:/opt/rbenv/bin:/opt/rbenv/shims:$PATH \
  bin/tootctl accounts delete mastodon.internal

Then:

bash
sudo -u mastodon RAILS_ENV=production \
  PATH=/opt/rbenv/versions/mastodon/bin:/opt/rbenv/bin:/opt/rbenv/shims:$PATH \
  bin/tootctl accounts delete garrett

These commands:

• Remove the local accounts (so they no longer appear on the instance).
• Send ActivityPub delete activities to other servers that know about those accounts, asking them to delete cached data.

This is a kind and responsible way to leave: you’re telling the rest of the network “these accounts are gone.”

Step 6: Enabling Mastodon’s self‑destruct mode

Recent versions of Mastodon have a “self‑destruct” feature that does a more global cleanup—broadcasting deletion notices and generally tidying up the instance.

Running:

bash
sudo -u mastodon RAILS_ENV=production \
  PATH=/opt/rbenv/versions/mastodon/bin:/opt/rbenv/bin:/opt/rbenv/shims:$PATH \
  bin/tootctl self-destruct

…didn’t immediately nuke the server. Instead, it prints:

text
To switch Mastodon to self-destruct mode, add the following variable to your environment (e.g. by adding a line to your `.env.production`) and restart all Mastodon processes:
  SELF_DESTRUCT=Im1hc3RvLmdhcnJldHQubGlmZSI=--16f00486726e21f1cdbd83aabd7aadbcec8aec1f
You can re-run this command to see the state of the self-destruct process.

The idea is: you prove you really mean it by putting that SELF_DESTRUCT value into your environment and restarting.

So I edit .env.production:

bash
cd /var/www/mastodon/live
nano .env.production

At the bottom of the file, I add:

text
SELF_DESTRUCT=Im1hc3RvLmdhcnJldHQubGlmZSI=--16f00486726e21f1cdbd83aabd7aadbcec8aec1f

Then I save and exit Nano (Ctrl+O, Enter, then Ctrl+X).

Step 7: Restarting services so self‑destruct kicks in

After setting the environment variable, I restart the Mastodon services so they would pick it up:

bash
systemctl restart mastodon-web
systemctl restart mastodon-sidekiq
systemctl restart mastodon-streaming

With that done, I run the self‑destruct command again:

bash
sudo -u mastodon RAILS_ENV=production \
  PATH=/opt/rbenv/versions/mastodon/bin:/opt/rbenv/bin:/opt/rbenv/shims:$PATH \
  bin/tootctl self-destruct

This time, the output says:

text
I, [2026-04-09T14:36:43.058382 #270437]  INFO -- : [dotenv] Loaded .env.production
Self-destruct mode is already enabled for this Mastodon server
INFO  2026-04-09T18:36:46.988Z pid=270437 tid=5utx: Sidekiq 8.0.9 connecting to Redis ...
Deletion notices are still being processed

Which means:

• Self‑destruct mode is active.
• Sidekiq is working through the queue, sending deletion notices out into the fediverse.

Now, we wait 10-15 minutes. You can re‑run the command periodically to see when it finishes.

When it’s done, it’ll say:

text
I, [2026-04-09T18:53:34.285921 #287308]  INFO -- : [dotenv] Loaded .env.production
Self-destruct mode is already enabled for this Mastodon server
INFO  2026-04-09T22:53:38.108Z pid=287308 tid=673w: Sidekiq 8.0.9 connecting to Redis with options {size: 10, pool_name: "internal", url: "redis://localhost:6379/0", driver: :hiredis}
Every deletion notice has been sent! You can safely delete all data and decomission your servers!

Step 8: Uninstalling Mastodon from YunoHost

Once I am satisfied that:

• All local accounts were deleted.
• Self‑destruct had been enabled and given time to process deletion notices.

…I remove the app from YunoHost.

In the YunoHost web admin:

1. I log into https://garrett.life/yunohost/admin as admin.
2. I go to Applications.
3. I click on the Mastodon app for masto.garrett.life.
4. I hit Remove / Uninstall and confirm.

YunoHost then removed:

• The Mastodon app files.
• The Mastodon database.
• The related services and system users.

At that point, the instance was gone from my server, and the space and memory are freed up for something else.

You’ve never heard of me, but I went $50,000 in debt trying to “make it” as a musician, mostly focused on playing the Spotify game.

You would think that much money spent would at least make me somewhat recognizable, so here’s my actual numbers:

I made about $85 in streaming, but a couple thousand dollars from direct music sales (Bandcamp and physical media sales).

I was playing the streaming game, but it’s just that — a game. Actually, there are several games to play. The release schedule game. The playlisting game. The social media game.

Spotify isn’t “the game”. Spotify is the casino full of different games to play.

And the house *always* wins.

Spotify says they paid out $10,000,000,000 (that’s ten billion dollars), but the average indie artist made under $1000 for the entire year.

(Wait…who’s making $1000 per year from Spotify?)

And thanks to Spotify’s 1000 play minimum for a single track to earn anything, that means 87% of tracks on Spotify did not generate any revenue for the artists. And over $40,000,000 in unpaid royalties.

Here’s the thing though:

Streaming didn’t fail us.

We’ve just been playing the wrong game(s).

Artists need to treat Spotify et al. like we did radio (when that was still a thing).

Spotify is a casino; we play the games; the house always wins.

When you go to a casino, there are lots of games to play. They’re pretty much all rigged.

Sort of. I mean, it’s legal, but, they’re all optimized so that you win just enough to get that dopamine hit and keep playing.

There’s a saying, “the house always wins.”

Because in the end, the casino makes all the money.

You’re unlikely to walk away with a big pay day.

And it’s near impossible to build a living as a “professional gambler.”

Streaming does the same thing to us.

You upload some music, and you get a little boost from the algorithm. You get some plays, and a few followers. It feels good. People like your music!

Maybe you get added to a playlist and a bunch more streams come through. Then you hit that 1000 plays threshold and you’ve got pennies trickling in.

That’s proof of concept right there. You can do this. You just need to keep it going. It’ll grow exponentially if you keep at it. That’s what they said.

So, you start researching how to play the games better. And you discover there are even more games to play.

You can play the single release game, instead of doing whole albums. That gets you a small amount of consistent plays early on.

You can play the playlisting game. That’s where your early boost came from that put you into the payment threshold.

You tap into Spotify’s Discovery Mode, where they pay you less (30% less!) but promise more promotion on their part. It’s worth it, right? They said it is. Why would they do it if it wasn’t? You just gotta get those release numbers up to make up for it.

Next thing you know, you’ve spent money on playlisting, Facebook ads, marketing courses, and anything else you could find.

And you’re getting plays! It’s not making the money back…yet…you just have to keep going!

For every 1000 streams you get, you make $3, up to $5 if you’re lucky.

You get that dopamine hit. That motivation to keep going.

But it’s small payouts.

And they never add up.

There Is Money In Music Sales

You need thousands of streams to make $10 on Spotify, but only one single sale of an album on Bandcamp.

I’m not here to shill for Bandcamp specifically. You can use WooCommerce on your own site (I do). Or Shopify. Or Ko-Fi. There are tons of options.

But I’m going to use Bandcamp because we have more statistics from them, more proof of concept.

Bandcamp has shown year after year people are willing to drop $10 or more on an album of music they like to support artists they admire.

And you keep over 80% of that.

There has also been an increase in physical media sales over the last few years.

People are buying cassettes and vinyl. People are buying CDs again! Wtf???

I don’t know why. I’m one of them, though. Personally I buy in this order of availability: cassette; if they don’t have it then a vinyl, if they don’t have it than a CD, if they don’t have it than digital download.

Bandcamp and other platforms like this don’t have super great discovery, though. They’re working on it, of course. I applaud them for that.

But if you’re like me and are obsessed with self-hosting and keeping as much money as possible, you get basically no discovery algorithm.

That’s where we go back to streaming, but we treat it like radio.

Streaming Is The New Radio (and we need to treat it that way).

It is true that we need streaming for discovery. That is the current dominating force in discovery, and we can’t get around that.

But before streaming, it was radio.

We didn’t release entire albums on radio for many reasons that are probably false equivalents for my argument so I’ll skip all that.

Streaming services know they are necessary for this, and that’s why they can pay us so little yet keep us coming back.

They know exactly what they’re doing, and they’re going to milk it for everything they can in the short term. They’ve optimized revenue for it.

So, we’re going to both let them, and not let them, at the same time.

By removing our albums and only releasing singles for the sake of discovery.

In a future post, I’ll really break down the “how to” in a guide that I’m working on (yes it will be a free blog post). Until then, let me keep it brief:

The way radio used to work was that you would put out a single ahead of an album release.

It builds hype, then the album comes out and you get (hopefully) lots of sales.

Drop another single shortly after.

Work some music videos in there.

Do a tour.

Sell some T-Shirts. Hopefully make lots of sales of those, too.

I 9001% believe we as artists can take back control from streaming services if we treat them like radio.

I mean heck they’re barely paying us anyway. Spotify Discovery mode where they keep 30% MORE of your earnings? Fine, Spotify; you can have it. But you’re only getting my singles.

I don’t even think a lot of, or even major artists, need to do this for this to succeed.

If one artist (me) does this, I think I will do just fine.

But the more of us are doing this, the better.

I’ll write more about this in the near future. I just wanted to get this idea out there now to start the momentum in 2026.

If you want to be notified of my follow-up posts, please subscribe to my email list:

https://sendfox.com/megabyteghost