Kalvin's Journal

Welcome! Greetings!

This document summarizes everything I did to set up and optimize a self-hosted Mastodon instance, with the specific goal of federating with my Threads account, while keeping system resource usage low. This includes systemd tuning, Sidekiq concurrency adjustments, federation limits, and selective media handling.

Why I Did This

I wanted to stay connected to the fediverse via Threads (which I'm verified on), but without committing fully to a busy Mastodon instance. My intent is not to host a large social server, but to run a minimal and functional one for the purpose of federation — particularly with Threads.

Environment

  • Server OS: Debian 11 via YunoHost
  • Mastodon install method: YunoHost application
  • Shell: SSH with sudo access
  • Mastodon user: mastodon (managed by YunoHost)
  • Instance type: Private/personal use

1. Sidekiq Concurrency Optimization

Goal

Limit Sidekiq's thread usage to avoid high memory and CPU consumption.

What I Did

  • Created a systemd override to force Sidekiq to run with only 2 threads (-c 2).

Final Working Override

File: /etc/systemd/system/mastodon-sidekiq.service.d/override.conf

[Service]
ExecStart=
ExecStart=/bin/bash -lc 'cd /var/www/mastodon/live && exec bundle exec sidekiq -c 2'

Then reloaded and restarted:

sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl restart mastodon-sidekiq

Verified With

systemctl status mastodon-sidekiq

Output showed:

"sidekiq ... [0 of 2 busy]"

Which confirmed that Sidekiq is now respecting the -c 2 limit.

2. Disabling Streaming Service

Goal

Reduce resource usage by disabling real-time updates, which are not essential for my use case.

What I Did

sudo systemctl disable --now mastodon-streaming

This turns off the WebSocket-based streaming component, meaning I need to manually refresh pages (or rely on polling from the front-end).

3. Limiting Federation Scope

Goal

Avoid excessive background traffic from large Mastodon instances that I don’t care about. Focus on Threads and maybe a few others.

What I Did

a. Enabled authorized_fetch

Edited /var/www/mastodon/live/config/settings.yml and added:

authorized_fetch: true

This means only instances I interact with (e.g., Threads) can request data from me.

b. Blocked Large Instances

Using the admin panel at:

https://<my-domain>/admin/domain_blocks

I blocked:

  • mastodon.social
  • mastodon.online
  • mstdn.social

Set to:

  • Severity: Suspend
  • Reject media: Yes

This prevents those busy instances from pulling posts or federating with mine.

4. Media Processing Preferences

Goal

Keep media handling efficient, but not disabled — I still want to allow video and audio uploads.

What I Chose

  • Did NOT disable video/audio transcoding (I want users to be able to upload media)
  • Kept default thumbnail sizes: 600x600 (thumbnail), 1200x1200 (preview)
  • Disabled media proxying to reduce bandwidth and storage pressure

.env.production settings

DISABLE_MEDIA_PROXY=true

This means remote images are not cached or served via my server — they’re loaded directly from their source.

5. Sidekiq Concurrency in .env.production (for clarity)

Even though systemd overrides enforce concurrency, I added this to .env.production as documentation or fallback:

SIDEKIQ_CONCURRENCY=2

This is safe, and it communicates intent in case someone else checks the environment later.

Other Notes

  • I used sudo su - mastodon to switch to the Mastodon user for commands.
  • On YunoHost, even the mastodon user requires sudo to edit .env.production, since it’s owned by root or protected.
  • The systemctl edit mastodon-sidekiq command failed to open a usable editor at first, so I manually created the override file at the correct path.
  • I did not set up external S3 storage — media is stored locally.

Conclusion

The Mastodon instance now:

  • Uses minimal Sidekiq workers (-c 2)
  • Has no streaming server running
  • Limits federation to only necessary servers (e.g., Threads)
  • Allows audio/video uploads
  • Doesn't proxy media (saves bandwidth)
  • Is ideal for quiet personal use, especially for verified Threads users like me who don’t want to give up the platform but still want a foothold in the fediverse.

Introduction

Over time, I've experimented with self-hosting a range of services—particularly Fediverse platforms—and discovered through trial, error, and burnout that not everything that can be self-hosted should be. Here's a reflection on what I've learned, what I’ll keep, and what I’ll let go of.

The Ideal vs. the Reality

I started with the idea that if software is open source and self-hostable, I should host it myself. The promise was enticing:

  • I own my data.
  • I control my presence.
  • I don’t depend on corporations.

But the reality is messier:

  • Federation is not free — it comes with server strain, disk bloat, and moderation burdens.
  • Running a public Fediverse instance, even just for myself, means dealing with spam, storage issues, federation bugs, and performance headaches.
  • Self-hosting doesn’t just give me power — it demands responsibility I wasn’t always ready for.

I learned that freedom includes the freedom to not take on more than I can sustain.

Lessons from Hosting Fediverse Instances

Mastodon

  • Every time I tried to host Mastodon with a broader federation scope, my server ballooned in disk usage. One time it hit 90GB out of 100GB within a single day.
  • I thought running a big instance would make me feel less alone online. Instead, it made me feel exhausted and fragmented.
  • I also kept migrating or deleting instances. Maybe my online friends got tired of trying to follow me as I hopped between accounts and domains.

Lemmy, Pixelfed, Mitra, WriteFreely

  • I tried them all, often running several at once.
  • They’re cool platforms, but running too many federated apps at once drained my system resources and my attention span.
  • Federation creates technical debt — and emotional labor, especially when things break or I feel the pressure to moderate.

The Deeper Realization

I don’t need to host the whole Fediverse. Just because it's open source doesn’t mean it belongs on my VPS. I can support the ecosystem by using it, donating to projects and admins, and contributing in ways that fit my energy level.

What I’m Keeping

1. A Minimal Mastodon Instance

  • I’ll keep one Mastodon instance for myself.
  • I’ll configure it in single-user mode, with public timelines off and registrations closed.
  • I’ll limit federation using allowed_domains and avoid relays.
  • I’ll actively manage media and statuses to avoid disk bloat.
  • I’ll use it as my digital journal, not a community platform.

2. Email via YunoHost

  • YunoHost has a built-in mail server, and I can generate as many addresses as I need.
  • I’ll use those to sign up for other Fediverse instances if needed.
  • This lets me engage in the broader network without having to run every node myself.

What I’m Letting Go Of

  • I no longer feel obligated to host everything I can.
  • I will not self-host large federated apps I don’t actively use or can’t sustain (like Lemmy or Pixelfed).
  • I will not run an open instance unless I have the energy and resources to handle moderation, abuse, and maintenance.

I’ve tried it. I know what it feels like. I don't owe anyone the labor of a free, open, federated social network just because I can type git clone.

My Current Stack and Strategy

Hosting (on a 8GB RAM / 100GB VPS)

  • Mastodon (lightweight, solo use)
  • YunoHost core system
  • Email server (for me only)
  • Possibly:
    • BookStack or WonderCMS (not both)
    • HedgeDoc for Markdown note-taking
    • LibreSpeed and Shell (httpsh) for utilities

Apps I’ve Removed or Will Avoid:

  • Lemmy
  • Pixelfed
  • Mitra
  • WriteFreely (if not in use)
  • Owncast
  • Redundant CMS apps
  • Any app that federates heavily without high personal benefit

Personal Philosophy Going Forward

I am hosting intentionally, not exhaustively.

I am not here to perform digital sovereignty, but to practice it with sanity.

I believe in self-hosting when it empowers me, not when it distracts me.

I support open-source projects by using them, donating when I can, and choosing to be part of the network without having to run the entire infrastructure myself.

My server is no longer a playground. It’s a garden. And I’ll tend only what I can care for.

Introduction

Over time, I've experimented with self-hosting a range of services—particularly Fediverse platforms—and discovered through trial, error, and burnout that not everything that can be self-hosted should be. Here's a reflection on what I've learned, what I’ll keep, and what I’ll let go of.

The Ideal vs. the Reality

I started with the idea that if software is open source and self-hostable, I should host it myself. The promise was enticing:

  • I own my data.
  • I control my presence.
  • I don’t depend on corporations.

But the reality is messier:

  • Federation is not free — it comes with server strain, disk bloat, and moderation burdens.
  • Running a public Fediverse instance, even just for myself, means dealing with spam, storage issues, federation bugs, and performance headaches.
  • Self-hosting doesn’t just give me power — it demands responsibility I wasn’t always ready for.

I learned that freedom includes the freedom to not take on more than I can sustain.

Lessons from Hosting Fediverse Instances

Mastodon

  • Every time I tried to host Mastodon with a broader federation scope, my server ballooned in disk usage. One time it hit 90GB out of 100GB within a single day.
  • I thought running a big instance would make me feel less alone online. Instead, it made me feel exhausted and fragmented.
  • I also kept migrating or deleting instances. Maybe my online friends got tired of trying to follow me as I hopped between accounts and domains.

Lemmy, Pixelfed, Mitra, WriteFreely

  • I tried them all, often running several at once.
  • They’re cool platforms, but running too many federated apps at once drained my system resources and my attention span.
  • Federation creates technical debt — and emotional labor, especially when things break or I feel the pressure to moderate.

The Deeper Realization

I don’t need to host the whole Fediverse. Just because it's open source doesn’t mean it belongs on my VPS. I can support the ecosystem by using it, donating to projects and admins, and contributing in ways that fit my energy level.

What I’m Keeping

1. A Minimal Mastodon Instance

  • I’ll keep one Mastodon instance for myself.
  • I’ll configure it in single-user mode, with public timelines off and registrations closed.
  • I’ll limit federation using allowed_domains and avoid relays.
  • I’ll actively manage media and statuses to avoid disk bloat.
  • I’ll use it as my digital journal, not a community platform.

2. Email via YunoHost

  • YunoHost has a built-in mail server, and I can generate as many addresses as I need.
  • I’ll use those to sign up for other Fediverse instances if needed.
  • This lets me engage in the broader network without having to run every node myself.

What I’m Letting Go Of

  • I no longer feel obligated to host everything I can.
  • I will not self-host large federated apps I don’t actively use or can’t sustain (like Lemmy or Pixelfed).
  • I will not run an open instance unless I have the energy and resources to handle moderation, abuse, and maintenance.

I’ve tried it. I know what it feels like. I don't owe anyone the labor of a free, open, federated social network just because I can type git clone.

My Current Stack and Strategy

Hosting (on a 8GB RAM / 100GB VPS)

  • Mastodon (lightweight, solo use)
  • YunoHost core system
  • Email server (for me only)
  • Possibly:
    • BookStack or WonderCMS (not both)
    • HedgeDoc for Markdown note-taking
    • LibreSpeed and Shell (httpsh) for utilities

Apps I’ve Removed or Will Avoid:

  • Lemmy
  • Pixelfed
  • Mitra
  • WriteFreely (if not in use)
  • Owncast
  • Redundant CMS apps
  • Any app that federates heavily without high personal benefit

Personal Philosophy Going Forward

I am hosting intentionally, not exhaustively.

I am not here to perform digital sovereignty, but to practice it with sanity.

I believe in self-hosting when it empowers me, not when it distracts me.

I support open-source projects by using them, donating when I can, and choosing to be part of the network without having to run the entire infrastructure myself.

My server is no longer a playground. It’s a garden. And I’ll tend only what I can care for.