Plausible en auto-hébergement, en une seule commande
Pendant un moment, railyard.run a tourné sans aucune analytique. Pas par principe — on n’avait simplement pas encore pris le temps, ce qui voulait dire que chaque « est-ce que quelqu’un lit vraiment ça » restait une hypothèse. Le régler est devenu le premier vrai test de si « auto-hébergé, en un clic » tient vraiment la route pour quelque chose qu’on utilise nous-mêmes, pas seulement pour ce qu’on construit pour les applications des autres.
Ce qu’on a lancé
Plausible Community Edition, comme gabarit de stack Railyard : trois services — Plausible lui-même, Postgres pour les données de l’application, et ClickHouse pour les événements d’analytique eux-mêmes — provisionnés ensemble sur un de nos propres serveurs.
railyard launch plausible --server <id>C’est toute l’étape de provisionnement. Pas de configuration séparée pour ClickHouse, pas de chaînes de connexion à câbler à la main — le gabarit déclare les trois services et comment ils se parlent, et Railyard déploie l’ensemble comme une seule unité.
Ce qui est venu après la commande de lancement
Le reste était le premier démarrage normal de n’importe quelle application auto-hébergée, rien de spécifique à Railyard :
- Ouvrir l’URL de l’application, s’inscrire comme propriétaire de l’instance — le propre flux de premier démarrage de Plausible, rien à préensemencer.
- + Add a website, entrer le domaine à suivre.
- Copier l’extrait de suivi généré et le coller dans le
<head>du site.
Aucun domaine personnalisé n’a même été nécessaire — l’URL par défaut en *.apps.railyard.run de l’application a suffi pour faire tourner le tableau de bord et servir le script de suivi. On n’utilise ce chemin que parce que c’est réellement plus simple, pas parce qu’il manquait quelque chose.
Où ça a cassé, brièvement
Ça n’a pas cassé — ce qui mérite d’être dit clairement, puisque tout l’intérêt de publier ce billet est d’être honnête sur ce que l’auto-hébergement coûte vraiment en pratique. Le gabarit s’est lancé proprement, les trois services se sont trouvés via le réseau privé de Railyard sans aucun câblage manuel de variables d’environnement, et le script de suivi a commencé à montrer des visites dans la vue Realtime de Plausible quelques secondes après avoir été ajouté au site.
La seule chose à savoir avant de s’y mettre : un nouveau lancement crée une nouvelle application à chaque fois qu’on l’exécute, donc lancer deux fois veut dire deux stacks complètes qui tournent côte à côte, pas une mise à jour de la première. Erreur facile, correction facile — apps:rm <nom> --confirm <nom> dans la CLI retire proprement celle en trop.
Pourquoi l’auto-hébergement plutôt que Plausible Cloud
Plausible Cloud est un bon produit et le choix le plus simple pour la plupart des équipes. On a choisi l’auto-hébergement précisément parce que c’est le même genre d’affirmation qu’on fait pour tout le reste sur Railyard : vous devriez pouvoir faire tourner les outils dont vous dépendez, sur une infrastructure que vous contrôlez, sans une deuxième relation fournisseur pour chaque pièce de votre pile. Sans cookies, sans bannière de consentement, et les données ne quittent jamais un serveur qu’on a nous-mêmes provisionné.
Si vous pesez le même compromis pour votre propre site, le gabarit Plausible est à un clic, et Logs, métriques et alertes couvre le reste de ce que Railyard montre sur le trafic sans une pile d’analytique séparée.