Operational Deep-Dive: Mastodon Instance on Anubiz Romania VPS

Default queue concurrency 25 is fine until federation spike. During a viral toot the default queue depth can climb past 5000 within minutes. Two strategies. First, run two Sidekiq processes on the default queue each with concurrency 25, giving 50 worker threads effective. Second, bump push queue concurrency to 25 because viral spike is mostly push deliveries.

Monitor via sidekiq-prometheus. Alert when default queue depth crosses 2000 sustained for 5 minutes.

The statuses table is the largest churn on a Mastodon instance. Default autovacuum is too conservative. Per-table override: autovacuum_vacuum_scale_factor=0.02, autovacuum_analyze_scale_factor=0.01, autovacuum_vacuum_cost_limit=2000. This runs vacuum more often, smaller jobs, less impact per run.

Run pg_repack monthly on statuses_pkey to reclaim space without long lock holds.

Local NVMe for media is fine until you hit 500 GB. Above that, move to S3-compatible object storage. Wasabi, Backblaze B2, or self-hosted MinIO on a separate VPS all work. Use the AWS-compatible env vars in Mastodon config; switch is hot-swappable for new media, and you can backfill old media via a one-time rsync to S3.

Mastodon depends on Redis for Sidekiq queue state. Single-Redis is fine for community instances but a Redis failure halts background processing. For a paid or important instance run Redis Sentinel with a second Redis on a peer VPS. Mastodon supports Sentinel config natively.

Symptoms: default queue depth climbs, push queue depth climbs, web response slows. Steps: 1) check Postgres connection pool exhaustion via pg_stat_activity; 2) check Sidekiq depth and worker thread saturation; 3) if Postgres is the bottleneck, raise pgbouncer pool size temporarily; 4) if Sidekiq is the bottleneck, spawn an extra default process; 5) post incident comm to instance once stabilized.

Internal: Romania VPS, VPS lineup, anonymous hosting, dedicated for multi-VPS scale-out.