Votre communauté.
Sur votre juridiction. Fédérée par défaut.

La délivrabilité e-mail. L'application Mastodon elle-même est bien conçue, la stack Docker Compose s'assemble en un après-midi, et le tuning Postgres est une science connue. La partie qui casse les instances, ce sont les confirmations d'inscription, les réinitialisations de mot de passe et les notifications de modération de fédération qui n'atteignent pas les boîtes Gmail / Outlook365 parce que le chemin SMTP depuis une IP de VPS neuve est traité comme coupable-jusqu'à-preuve-du-contraire. Prévoyez un relais mail transactionnel externe (Mailgun, Postmark, Amazon SES) dès le premier jour — cela coûte $10/mo et supprime 80 % de la douleur opérationnelle.

La base Postgres de Mastodon croît approximativement proportionnellement à l'union de « ce que postent vos utilisateurs locaux » plus « tout ce qui vient de chaque compte que n'importe qui ici a jamais suivi sur n'importe quelle autre instance ». Pour une instance de 100 utilisateurs actifs avec une fédération sortante saine, attendez-vous à 20 à 40 GB de base après la première année et 80 à 150 GB après trois ans. Les médias (images / vidéos / boosts uploadés) vivent séparément et constituent le plus gros problème de stockage — voir la question suivante.

Oui, et vous devriez. Mastodon supporte tout backend compatible API S3 via la variable d'env S3_ENABLED. NordBastion n'opère pas actuellement de stockage objet first-party, le choix pragmatique est donc un fournisseur externe — Backblaze B2 est la recommandation standard pour les instances auto-hébergées (prix prévisibles, pas de frais d'egress quand on l'associe à Cloudflare en façade). Avec les médias déportés, les 480 GB NVMe d'un Ravelin tiennent Postgres et les queues de jobs Sidekiq pendant des années ; sans déport, les mêmes 480 GB se remplissent en 12 à 18 mois sur une instance modérément active.

Ravelin (8 vCPU, 16 GB, 480 GB) est confortable jusqu'à ~100 utilisateurs postant activement par jour avec une fédération sortante saine. Le goulot qui casse en premier, ce sont les workers Sidekiq sous des bursts de fédération entrante (un post viral boosté par une instance de 50k utilisateurs produit un pic transitoire de queue qui veut plus de workers, qui veut plus de RAM). À ~300 utilisateurs actifs ou dès que les jobs traités/sec Sidekiq se maintiennent au-delà de 100 en régime soutenu, le palier Bulwark gagne sa place — plus de cœurs, plus de marge RAM, et la liberté de dédier un cœur à Elasticsearch si vous voulez la recherche.

La défédération, c'est quand votre instance (ou une autre instance) cesse d'accepter les messages d'un pair — utilisée en pratique pour bloquer les instances qui hébergent du contenu violant vos standards de communauté. L'UI d'admin Mastodon expose des bascules suspend/silence/limit par instance ; le coût social est réel (vos utilisateurs perdent les fils dans lesquels ils étaient avec des gens sur l'instance bloquée) et le coût de modération est réel (quelqu'un doit prendre la décision). L'intérêt de faire tourner votre propre instance, c'est que cette décision vous appartient — basée sur vos standards de communauté, pas sur un pipeline corporate trust-and-safety.

Pour une instance de moins de ~50 utilisateurs avec inscriptions filtrées (sur invitation ou validation admin), la modération est de quelques minutes par semaine — fermer les rapports de comptes spam, limiter occasionnellement une instance pair. Pour les instances en inscription ouverte, l'effort croît de façon super-linéaire avec le volume d'inscriptions parce que l'économie des spam-bots traite chaque endpoint ActivityPub ouvert comme une cible. La défense standard, ce sont les inscriptions avec validation requise + une question d'application claire — fait chuter les inscriptions automatisées de 99 % avec une friction négligeable pour les humains réels.

Oui, pour une raison précise et sous-estimée : en tant qu'admin vous recevez des rapports de modération, des demandes de retrait, et la demande RGPD de personne concernée occasionnelle. La Suède, la Finlande, la Norvège et l'Islande ont un cadre légal bien défini sur ce que doivent un hébergeur et un petit opérateur de forum en réponse — et surtout, pas d'équivalent de la machinerie DMCA américaine notice-and-staydown qui laisse une seule accusation forcer un retrait préventif. Vous modérez quand même ; vous le faites simplement à vos conditions plutôt que sous la menace d'une action automatique de l'hébergeur.

Côté hébergement : Mastodon est le plus lourd (Ruby on Rails + Sidekiq + Postgres + Redis + Elasticsearch optionnel), Pleroma/Akkoma sont plus légers (Elixir, release OTP unique), la famille Sharkey/Misskey tourne sur Node + Postgres. Un Ravelin gère n'importe lequel d'entre eux confortablement pour ~100 utilisateurs ; un Sentinel peut faire tourner Pleroma/Akkoma pour un usage instance personnelle là où le même palier ne suffirait pas pour Mastodon. Choisissez sur l'adéquation communauté (quelles fonctionnalités comptent, quelle UI vos gens préfèrent), pas sur la courbe de ressources — la différence est petite à cette échelle.