La sua comunità.
Sulla sua giurisdizione. Federata per default.

La deliverability dell'email. L'applicazione Mastodon in sé è ben progettata, lo stack Docker Compose si assembla in un pomeriggio e la messa a punto di Postgres è scienza nota. La parte che rompe le istanze delle persone sono le conferme di signup, i reset password e le notifiche di moderazione di federazione che non riescono a raggiungere le inbox Gmail / Outlook365 perché il percorso SMTP da un IP VPS fresco è trattato come colpevole-fino-a-prova-contraria. Pianifichi un relay mail transazionale esterno (Mailgun, Postmark, Amazon SES) dal primo giorno — costa $10/mese e rimuove l'80% del dolore operativo.

Il database Postgres di Mastodon cresce grosso modo proporzionalmente all'unione di «ciò che pubblicano i suoi utenti locali» più «tutto da ogni account che chiunque qui abbia mai seguito su ogni altra istanza». Per un'istanza con 100 utenti attivi e una sana federazione in uscita, si aspetti 20-40 GB di database dopo il primo anno e 80-150 GB dopo tre anni. I media (immagini / video / boost caricati) vivono separatamente e sono il problema di storage più grande — veda la domanda successiva.

Sì, e dovrebbe. Mastodon supporta qualsiasi backend compatibile con l'API S3 via la env var S3_ENABLED. NordBastion attualmente non gestisce storage a oggetti di prima parte, quindi la scelta pragmatica è un provider esterno — Backblaze B2 è la raccomandazione standard per le istanze self-hosted (prezzi prevedibili, nessuna fee di egress quando abbinato a Cloudflare davanti). Con i media scaricati, i 480 GB NVMe di un Ravelin contengono Postgres e le code di job Sidekiq per anni; senza scarico, gli stessi 480 GB si riempiono in 12-18 mesi su un'istanza moderatamente attiva.

Ravelin (8 vCPU, 16 GB, 480 GB) è comodo fino a ~100 utenti giornalieri che postano attivamente con una sana federazione in uscita. Il collo di bottiglia che si rompe per primo sono i worker Sidekiq sotto raffiche di federazione in entrata (un post virale boostato da un'istanza di 50k utenti produce un picco di coda transitorio che vuole più worker, che vuole più RAM). A ~300 utenti attivi o quando i Sidekiq processed-jobs/sec si attestano >100 sostenuti, la fascia Bulwark guadagna il suo posto — più core, più margine RAM e la libertà di dedicare un core a Elasticsearch se vuole la ricerca.

La defederazione è quando la sua istanza (o un'altra istanza) smette di accettare messaggi da un peer — usata in pratica per bloccare istanze che ospitano contenuto in violazione dei suoi standard di comunità. L'UI amministrativa di Mastodon espone toggle per-istanza di suspend/silence/limit; il costo sociale è reale (i suoi utenti perdono i thread in cui erano con persone sull'istanza bloccata) e il costo di moderazione è reale (qualcuno deve prendere la decisione). Il senso di gestire la propria istanza è che questa è una decisione sua — basata sugli standard della sua comunità, non su una pipeline corporate trust-and-safety.

Per un'istanza sotto ~50 utenti con signup curati (su invito o approvati dall'admin), la moderazione richiede pochi minuti a settimana — chiudere segnalazioni di account spam, occasionalmente limitare un'istanza peer. Per le istanze a registrazione aperta lo sforzo scala in modo superlineare con il volume di signup perché l'economia delle spam-bot tratta ogni endpoint ActivityPub aperto come un bersaglio. La difesa standard sono registrazioni richiedenti approvazione + una chiara domanda di candidatura — riducono i signup automatici del 99% con un attrito trascurabile per umani reali.

Sì, per una ragione specifica e sottovalutata: come admin riceve segnalazioni di moderazione, richieste di rimozione e l'occasionale richiesta GDPR del soggetto dei dati. Svezia, Finlandia, Norvegia e Islanda hanno un framework giuridico ben definito su ciò che un hoster e un piccolo operatore di forum devono in risposta — e cosa cruciale, nessun equivalente del meccanismo notice-and-staydown del DMCA statunitense che permette a una singola accusa di forzare una rimozione preventiva. Modera comunque; semplicemente lo fa alle sue condizioni anziché sotto minaccia di un'azione automatica dell'hoster.

Lato hosting: Mastodon è il più pesante (Ruby on Rails + Sidekiq + Postgres + Redis + Elasticsearch opzionale), Pleroma/Akkoma sono più leggeri (Elixir, singola release OTP), Sharkey/famiglia-Misskey girano su Node + Postgres. Un Ravelin gestisce comodamente uno qualsiasi di essi per ~100 utenti; un Sentinel può far girare Pleroma/Akkoma per uso a istanza personale dove la stessa fascia non basterebbe per Mastodon. Scelga in base alla compatibilità con la comunità (quali funzionalità contano, quale UI preferisce la sua gente), non in base alla curva di risorse — la differenza è piccola a questa scala.