Faut-il auto-héberger Teable ?
Guide de décision sur le dépôt officiel, les responsabilités d’exploitation, les compromis cloud et les vérifications avant production.
Réponse courte : Auto-héberger Teable signifie exécuter l’application sur des serveurs contrôlés par votre équipe plutôt que sur Teable Cloud. Vous contrôlez le réseau et les données, mais vous assumez la base, le stockage des fichiers, le domaine, TLS, les secrets, les sauvegardes, les mises à jour, la supervision et les incidents.
Ce que cela comprend
Lancer un conteneur ne suffit pas : connectez la base et le stockage des pièces jointes, protégez les variables d’environnement, configurez HTTPS et maintenez une version compatible. Testez la restauration des sauvegardes et prévoyez un retour arrière pour chaque mise à jour. Le README officiel propose Cloud et fully self-hosted.
Pourquoi le choisir
L’auto-hébergement peut garder les données dans un réseau privé, satisfaire une règle de résidence et laisser l’équipe choisir ses fenêtres de maintenance et contrôles d’identité. Il convient surtout si vous exploitez déjà PostgreSQL et l’observabilité ; économiser le serveur seul sous-estime le temps d’ingénierie.
Coût et décision
Avec Cloud, le fournisseur prend en charge une grande partie de l’exploitation. En auto-hébergement, votre équipe applique les correctifs, renouvelle les certificats, fait tourner les secrets, règle la base, conserve les pièces jointes, restaure les sauvegardes et répond aux pannes. Nommez les responsables et testez restauration et retour arrière hors production. Choisissez Cloud pour la vitesse et moins d’opérations ; choisissez l’auto-hébergement seulement si le contrôle justifie cette charge.
Ce guide aide à décider, mais ne remplace pas un runbook de capacité. Consultez la documentation officielle et le dépôt canonique.