Héberger Mastodon sur un VPS : monter sa propre instance du fédiverse, en toute lucidité

Vous voulez quitter Twitter/X pour un réseau social que vous contrôlez vraiment, sous votre propre nom de domaine, avec votre charte et vos règles ? Mastodon est le candidat le plus connu du fédiverse, cet ensemble d’instances décentralisées qui communiquent entre elles via le protocole ActivityPub. Chaque instance est un petit serveur autonome, mais toutes forment un réseau global : un membre de votre instance peut suivre et répondre à quelqu’un hébergé à l’autre bout du monde, comme s’ils étaient sur la même plateforme.

L’idée est séduisante, et héberger sa propre instance sur un VPS loué offre quelque chose qu’aucun réseau centralisé ne donnera jamais : la maîtrise totale de vos données, de votre modération et de votre image. Mais soyons honnêtes dès la première ligne, parce que c’est l’information la plus utile de toute cette page : Mastodon est exigeant, lourd, et ce n’est pas un projet à lancer à la légère. Pour beaucoup de gens, ce n’est tout simplement pas le bon choix — et nous allons commencer par expliquer pourquoi.

Faut-il vraiment héberger sa propre instance Mastodon ?

Posons la question franchement, avant même de parler technique : avez-vous réellement besoin de votre propre serveur ?

Pour un usage individuel, la réponse est presque toujours non. Le fédiverse a une particularité magnifique que les réseaux centralisés n’ont pas : vous pouvez profiter de Mastodon à 100 % sans héberger quoi que ce soit. Il vous suffit de créer un compte sur une instance existante — mastodon.social, piaille.fr, mamot.fr (tenue par La Quadrature du Net), une instance thématique sur la photo, le jeu vidéo ou votre région. C’est gratuit, c’est immédiat, c’est modéré par d’autres, et surtout c’est zéro maintenance. Vous suivez qui vous voulez partout dans le fédiverse, exactement comme si vous aviez votre propre serveur. Monter une instance juste pour soi, c’est se condamner à entretenir une machine entière pour un seul utilisateur — un effort disproportionné, et nous serions malhonnêtes de vous y pousser pour vendre un VPS.

Alors quand héberger sa propre instance a-t-il du sens ? Dans des cas bien précis :

• Une marque ou une entreprise qui veut une présence officielle sous son domaine (@contact@social.mamarque.fr), gage d’authenticité et de contrôle de son image.
• Une communauté (association, collectif, club, média, projet open source) qui veut son espace dédié, sa charte, sa culture, et garder ses membres ensemble.
• Une association ou une organisation soucieuse de souveraineté : ses données et celles de ses membres restent sur son infrastructure, en Europe, hors d’un réseau publicitaire.
• Le contrôle total, par principe : vos règles, votre modération, aucune décision arbitraire d’une plateforme tierce qui suspend un compte du jour au lendemain.

Dans ces situations, l’auto-hébergement devient légitime et même puissant. Mais il faut entrer dans le projet les yeux ouverts : ce n’est pas « installer une appli », c’est faire tourner un petit service en ligne avec ce que cela implique de ressources, de coûts croissants et de responsabilités. La suite de ce guide vous donne tous les chiffres pour décider en connaissance de cause.

Configuration requise : combien de RAM pour Mastodon ?

C’est ici que Mastodon se distingue de la plupart des applications de ce site. Là où un blog ou un outil de notes tient sur un seul conteneur léger, Mastodon est une architecture en plusieurs services qui tournent en parallèle, et qui consomment chacun leur part de mémoire :

• Le serveur web (l’application Ruby on Rails) qui sert l’interface et l’API.
• Le service de streaming (Node.js) qui pousse les nouveaux messages en temps réel dans les colonnes — c’est lui qui fait que votre fil se met à jour tout seul.
• Sidekiq, le moteur de files d’attente. C’est la pièce la plus importante à comprendre : presque tout ce que fait Mastodon en coulisses passe par Sidekiq — distribuer vos messages aux autres instances, recevoir les leurs, télécharger les médias distants, envoyer les e-mails, calculer les fils. Sur une instance active, Sidekiq peut être le plus gros consommateur de CPU et de RAM.
• PostgreSQL, la base de données : tous les comptes, messages, abonnements et signalements y vivent.
• Redis, qui sert à la fois de cache et de support aux files d’attente de Sidekiq.

Additionnez tout cela et vous comprenez la règle : 4 Go de RAM, c’est le strict minimum pour une petite instance, et 6 Go et plus pour respirer dès que vous dépassez quelques dizaines de membres actifs. Sur un VPS à 2 Go, l’expérience est connue et décourageante : il faut arrêter des services pour faire tourner la moindre tâche de maintenance, et le système tue régulièrement Sidekiq ou PostgreSQL au premier pic. Côté CPU, visez 2 à 4 vCPU pour que Sidekiq encaisse les rafales de fédération sans figer l’interface. Si vous hésitez plus largement sur le dimensionnement, ce guide détaille les ordres de grandeur : combien de RAM pour le self-hosting.

Le vrai coût caché : stockage des médias et fédération

Voici le piège que personne ne voit venir, et qui transforme un budget « fixe » en facture qui grimpe : le stockage des médias.

Le mécanisme est inhérent au fonctionnement du fédiverse. Quand vos membres suivent des comptes hébergés sur d’autres instances, Mastodon télécharge et met en cache les images, vidéos, avatars et aperçus de liens de ces comptes distants, pour les afficher rapidement chez vous. Autrement dit, votre disque ne stocke pas seulement vos médias : il accumule une copie de ceux de tout le réseau que vos abonnements touchent. Concrètement, même une petite instance d’un ou deux utilisateurs peut engranger plusieurs gigaoctets de médias par mois sans que personne ne publie grand-chose. Plus votre communauté suit de monde, plus le cache enfle vite.

Conséquence : un disque de 40 Go qui paraît confortable au départ peut se remplir en quelques mois. Deux réflexes s’imposent donc dès le début :

• Nettoyer régulièrement le cache des médias distants. Mastodon fournit l’outil tootctl media remove, qui supprime les médias en cache plus anciens qu’un certain délai (par exemple 14 jours). On le planifie via une tâche cron. C’est indolore : les médias distants seront re-téléchargés à la demande si besoin.
• Déporter les médias sur un stockage objet S3 dès que ça grandit. Plutôt que de gonfler le disque du VPS, on configure Mastodon pour écrire les médias dans un bucket compatible S3 (chez un hébergeur européen, ou un MinIO auto-hébergé). On paie alors le stockage à l’usage, et on découple la croissance des médias de la taille du serveur.

Et n’oubliez pas la brique sans laquelle rien ne démarre vraiment : le SMTP. Mastodon a besoin d’un serveur d’envoi d’e-mails pour la confirmation des inscriptions, les réinitialisations de mot de passe et les notifications. Sans SMTP fonctionnel, personne ne peut même valider son compte. On branche un service d’envoi transactionnel (le SMTP de l’hébergeur, Brevo, Mailgun, Postmark…) plutôt que d’envoyer depuis le VPS, faute de quoi vos e-mails finiront en spam.

La modération : un engagement, pas qu’une techno

C’est le chapitre qu’on saute trop souvent, et c’est peut-être le plus déterminant. Ouvrir une instance Mastodon, c’est devenir responsable de ce qui s’y passe. Ce n’est pas un détail juridique abstrait : c’est un engagement concret, à la fois légal et humain.

Côté humain, dès que des membres s’inscrivent, vous héritez des signalements : contenus problématiques, conflits, harcèlement, spam. Quelqu’un doit les lire et trancher. Vous devrez aussi décider de votre politique vis-à-vis des autres instances : en accepter certaines, en bloquer d’autres (la « défédération ») quand elles hébergent des contenus que vous refusez de voir arriver chez vos membres. Ces décisions façonnent l’expérience de votre communauté et engagent votre responsabilité.

Côté légal, en tant qu’hébergeur du contenu publié sur votre instance, vous êtes tenu de réagir face aux contenus manifestement illégaux qui vous sont signalés. Une instance ouverte aux inscriptions sans aucune surveillance dérive vite — et une instance laissée à l’abandon côté modération devient un problème pour tout le fédiverse, qui finira par la bloquer en masse.

La leçon est simple : la technique n’est que la moitié du travail. Avant d’ouvrir les inscriptions, demandez-vous qui modérera, selon quelles règles, et avec quel temps disponible. Une bonne pratique consiste à démarrer sur invitation ou avec des inscriptions fermées, le temps de roder la modération, plutôt que d’ouvrir grand les portes le premier jour. Si vous n’avez pas les bras pour cela, c’est un signal fort que rejoindre une instance existante est le bon choix.

Combien coûte l’auto-hébergement de Mastodon ?

Mettons les chiffres à plat, sans enjoliver. Mastodon n’est pas l’application la moins chère de ce catalogue, et de loin. Trois postes se cumulent.

Le VPS, d’abord. Vu la RAM nécessaire (4 Go minimum, 6 Go conseillés) et les 2 à 4 vCPU pour Sidekiq, vous partez sur un palier supérieur à l’entrée de gamme. Comptez environ 12 à 20 €/mois pour une machine correctement dimensionnée chez un hébergeur sérieux — là où un blog ou un outil de notes se contente d’un VPS à 5–7 €.

Le stockage, ensuite, et c’est le poste évolutif. Le disque inclus suffit au lancement, mais la fédération le remplit. Selon votre politique de nettoyage et la taille de votre communauté, vous ajouterez tôt ou tard du stockage objet S3 facturé à l’usage. Ce coût démarre bas mais ne fait que monter avec l’activité — c’est la grande différence avec les applications à empreinte stable.

Le temps, enfin, qui n’apparaît sur aucune facture mais qui est le vrai prix de Mastodon : mises à jour régulières (le projet bouge vite), surveillance du disque et de Sidekiq, sauvegardes, et bien sûr la modération évoquée plus haut. Pour une instance communautaire, ce temps n’est pas anecdotique.

Le verdict honnête : si votre objectif est de publier du contenu pas cher, Mastodon n’est pas la bonne porte d’entrée — un blog Ghost coûte deux à trois fois moins et ne se fédère avec personne. Mastodon se justifie quand la valeur est dans la communauté et le contrôle, pas dans l’économie. Pour une marque ou une association qui tient à sa souveraineté sociale, 12–20 €/mois plus le temps est un prix raisonnable ; pour un particulier seul, c’est un coût et une charge sans contrepartie.

Quel hébergeur choisir pour Mastodon ?

Le réflexe ici est double. D’abord, ne prenez jamais le plus petit plan : visez d’emblée un palier 6 Go de RAM avec 2 à 4 vCPU, et vérifiez que vous pourrez monter en gamme facilement (ajouter de la RAM, du disque, ou brancher du stockage objet) sans tout réinstaller — car une instance qui marche, ça grandit. Ensuite, la localisation compte : pour une communauté francophone, héberger en France ou en UE est cohérent, à la fois pour la latence et pour la souveraineté des données de vos membres. OVHcloud (France) et Infomaniak (suisse, datacenters et garanties UE solides) cochent ces cases avec un excellent rapport qualité-prix ; Hetzner (Allemagne) offre des VPS généreux en RAM à prix serré, idéal quand le budget est le critère premier. Pensez aussi au stockage objet proposé par l’hébergeur : pouvoir brancher un bucket S3 « maison » à côté du VPS simplifie beaucoup la gestion des médias.

Installer Mastodon sur un VPS avec Docker

Voici un docker-compose.yml réaliste réunissant les cinq services indispensables : web, streaming, sidekiq, db (PostgreSQL) et redis. Les trois services Mastodon partagent le même fichier .env.production, que vous générerez de façon interactive : Mastodon fournit un assistant qui pose les questions clés (domaine, base, Redis, SMTP, stockage des médias) et écrit la configuration pour vous.

services:
  db:
    image: postgres:15-alpine
    container_name: mastodon-db
    environment:
      POSTGRES_USER: "mastodon"
      POSTGRES_PASSWORD: "motdepasse_pg"
      POSTGRES_DB: "mastodon_production"
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    container_name: mastodon-redis
    volumes:
      - ./data/redis:/data
    restart: unless-stopped

  web:
    image: ghcr.io/mastodon/mastodon:latest
    container_name: mastodon-web
    command: bundle exec puma -C config/puma.rb
    env_file: .env.production
    depends_on:
      - db
      - redis
    ports:
      - "3000:3000"
    volumes:
      # Médias en local au départ ; déportez-les sur S3 quand ça grandit.
      - ./data/public-system:/mastodon/public/system
    restart: unless-stopped

  streaming:
    image: ghcr.io/mastodon/mastodon-streaming:latest
    container_name: mastodon-streaming
    command: node ./streaming
    env_file: .env.production
    depends_on:
      - db
      - redis
    ports:
      - "4000:4000"
    restart: unless-stopped

  sidekiq:
    image: ghcr.io/mastodon/mastodon:latest
    container_name: mastodon-sidekiq
    command: bundle exec sidekiq
    env_file: .env.production
    depends_on:
      - db
      - redis
    volumes:
      - ./data/public-system:/mastodon/public/system
    restart: unless-stopped

Quelques points de vigilance, dans l’ordre :

• Générez la configuration en interactif d’abord. Avant le premier up, lancez l’assistant : il crée les clés secrètes, initialise la base et produit .env.production. Typiquement :

docker compose run --rm web bundle exec rails mastodon:setup

Répondez à chaque question (domaine, PostgreSQL, Redis, SMTP, stockage des médias). C’est ici que vous décidez du disque local ou du S3 pour les médias — un choix structurant.

• Le SMTP n’est pas optionnel. Sans serveur d’envoi valide, aucune inscription ne peut être confirmée. Renseignez-le pendant le setup.

• Reverse proxy HTTPS obligatoire. Placez Caddy, Traefik ou Nginx devant les ports 3000 (web) et 4000 (streaming) pour un certificat Let’s Encrypt automatique. Avec Caddy, le streaming doit être routé sur le chemin /api/v1/streaming :

social.mondomaine.fr {
    handle_path /api/v1/streaming/* {
        reverse_proxy localhost:4000
    }
    reverse_proxy localhost:3000
}

• Créez le compte propriétaire une fois la stack démarrée, avec l’outil d’administration tootctl :

docker compose exec web tootctl accounts create monpseudo \
  --email vous@mondomaine.fr --confirmed --role Owner

• Planifiez le nettoyage des médias et sauvegardez la base. Une tâche cron qui exécute tootctl media remove --days 14 garde le disque sous contrôle ; et c’est le volume PostgreSQL qu’il faut impérativement sauvegarder — il contient comptes, messages et abonnements. Le cache des médias distants, lui, est reconstructible.

Une fois en ligne, vous disposez de votre propre instance du fédiverse, sous votre domaine, prête à fédérer avec le reste du réseau — avec, en contrepartie, tout ce que ce guide a décrit honnêtement : des ressources, un coût qui évolue, et une modération à tenir.

Mastodon est l’application la plus exigeante de ce site, et nous n’allons pas prétendre l’inverse : avant de louer un serveur, posez-vous d’abord la vraie question — un usage personnel se contente très bien d’une instance existante, gratuite et sans maintenance. L’auto-hébergement se justifie pour une marque, une communauté ou une association prêtes à investir du temps autant que de l’argent. Si c’est votre cas, dimensionnez la machine avec soin : commencez par quel VPS choisir pour le self-hosting, puis vérifiez le palier de RAM avec combien de RAM pour s’auto-héberger. Et si votre but était surtout de publier du contenu, Ghost sera plus simple et bien moins cher.