Comment auto-héberger Baserow en 2026 : données, URL et sauvegardes tout-en-un

Un conteneur Baserow peut être opérationnel alors que la fonctionnalité attendue par les utilisateurs est défaillante. Avec Baserow, le problème caché vient généralement du fait que l’URL publique change après la génération de liens de partage et de callback par les utilisateurs. Ce guide considère comme test d’acceptation le scénario « créer une base de données et une vue, importer un CSV, modifier des lignes depuis deux sessions et téléverser un fichier avant de redémarrer la stack tout-en-un », puis construit le déploiement à rebours à partir de ce résultat.

Baserow joue un rôle précis dans la stack : des bases de données de type Airtable reposant sur Postgres et Redis. La question à se poser en production n’est donc pas de savoir si le port 80 répond une fois, mais si l’état, les dépendances et l’adresse publique restent cohérents après un redémarrage, une mise à jour et une restauration.

Les dépendances de Baserow

La santé du processus et celle du produit sont deux choses distinctes pour Baserow. Le port 80 peut répondre alors que la transaction côté utilisateur échoue toujours. L’exigence d’exécution locale est de disposer de suffisamment de mémoire pour Postgres, Redis, le backend et les workers intégrés. Gardez son cycle de vie explicite afin que déplacer Baserow d’un hôte à un autre ne modifie pas silencieusement son comportement.

Utilisez cet exercice de validation après toute modification importante de la configuration : créer une base de données et une vue, importer un CSV, modifier des lignes depuis deux sessions et téléverser un fichier avant de redémarrer la stack tout-en-un. Évitez d’inclure des vérifications externes coûteuses dans les probes de liveness afin qu’une panne d’un fournisseur ne provoque pas une boucle de redémarrage. Le dimensionnement doit suivre Postgres, Redis et les workers Celery intégrés, ainsi que le nombre de lignes, la taille des imports et le nombre d’éditeurs simultanés : ces indicateurs reflètent mieux la charge réelle de Baserow que les requêtes de pages.

Une base Docker pour Baserow

La commande suivante rend la frontière du conteneur visible sans prétendre provisionner tous les services externes.

docker run -d \
  --name baserow \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v baserow-data:/baserow/data \
  -e SECRET_KEY=replace-with-a-long-random-value \
  baserow/baserow:latest

Avant d’ouvrir l’ingress, inspectez l’environnement résolu, les montages et le listener. Vérifiez l’exigence locale avant toute exposition : suffisamment de mémoire pour Postgres, Redis, le backend et les workers intégrés. Un lancement réussi se termine lorsque vous pouvez créer une base de données et une vue, importer un CSV, modifier des lignes depuis deux sessions et téléverser un fichier avant de redémarrer la stack tout-en-un, et non lorsque docker ps affiche Up.

Domaines, en-têtes du proxy et port 80

Exposez un seul hostname HTTPS pour Baserow et gardez le port 80 brut privé. Définissez BASEROW_PUBLIC_URL sur l’origine externe exacte. Les navigateurs et les clients API n’apprendront ainsi pas deux adresses concurrentes.

Depuis un client vierge, exécutez la transaction validée et inspectez la première requête qui échoue. Utilisez le guide sur les domaines personnalisés lorsque le DNS ou TLS pose problème. Considérez « l’URL publique change après la génération de liens de partage et de callback par les utilisateurs » comme un diagnostic applicatif distinct une fois que la route est validée.

Sauvegarder l’état que Baserow ne peut pas recréer

Définissez le recovery point et le recovery time de Baserow en prenant en compte l’intégralité de l’arborescence /baserow/data et des exports logiques périodiques de la base de données. Montez /baserow/data avant le bootstrap, écrivez des données de test inoffensives, puis remplacez le conteneur afin de vérifier que ce chemin est réellement persistant. Un volume nommé assure la persistance lors d’un redeploy ; il ne protège ni contre une compromission ni contre la perte du serveur.

Construisez un environnement de restauration vierge, utilisez la même version applicative épinglée et vérifiez que les tables, les vues, les utilisateurs, les automatisations et les fichiers sont restaurés depuis la sauvegarde complète de /baserow/data. Consignez les commandes, les corrections de permissions et le temps écoulé. Le guide des sauvegardes fournit une bonne référence : une sauvegarde est considérée comme fiable après sa restauration, et non après son téléversement.

Ne donnez pas à Baserow accès à tout l’hôte

Analysez les actions effectuées par Baserow, et pas uniquement son formulaire de connexion. Dans ce cas, l’erreur à haut risque consiste à utiliser l’image tout-en-un sans plan de sauvegarde pour ses services intégrés. Mettez en place cette limite : désactivez les inscriptions lorsque c’est nécessaire, préservez SECRET_KEY et limitez les vues partagées publiquement aux données prévues.

Générez SECRET_KEY une seule fois, gardez-la hors de Git et conservez-la avec le recovery manifest, car sa modification peut invalider l’état chiffré ou signé de l’application. Ne résolvez pas une erreur de permissions en exécutant le conteneur en tant que root ou en montant largement l’hôte. Les limites de ressources font également partie de la conception de sécurité lorsque Postgres, Redis et les workers Celery intégrés, le nombre de lignes, la taille des imports et le nombre d’éditeurs simultanés peuvent être sollicités par les utilisateurs.

Des logs qui répondent à la question suivante

Un health check effectué lorsque le système est inactif ne dit pas grand-chose sur Baserow. Surveillez Postgres, Redis et les workers Celery intégrés, ainsi que le nombre de lignes, la taille des imports et le nombre d’éditeurs simultanés, puis déclenchez des alertes sur le symptôme observé par les utilisateurs : l’échec de l’action « créer une base de données et une vue, importer un CSV, modifier des lignes depuis deux sessions et téléverser un fichier avant de redémarrer la stack tout-en-un ». Gardez la liveness locale et peu coûteuse ; laissez la readiness signaler les migrations ou l’initialisation sans provoquer une tempête de redémarrages.

La zone de mise à jour la plus risquée tient au fait que l’image tout-en-un déplace plusieurs services simultanément. Les migrations de la base de données et de l’application doivent donc être répétées à partir d’un snapshot. Lisez les release notes, créez un snapshot de l’état, déployez la version cible sur une copie restaurée et répétez l’action d’acceptation. Si l’URL publique change après la génération de liens de partage et de callback par les utilisateurs, corrélez la requête client avec le premier log applicatif pertinent au lieu de supprimer l’état ou d’ajouter des redirections à l’aveugle.

Cinq vérifications plus solides que la santé du conteneur

Avant l’arrivée des vrais utilisateurs, créez une fiche de mise en production pour Baserow. Elle doit indiquer l’image épinglée, le port 80, l’origine canonique, les chemins persistants et le responsable de la mémoire suffisante pour Postgres, Redis, le backend et les workers intégrés. Ajoutez le résultat attendu de cette transaction : créer une base de données et une vue, importer un CSV, modifier des lignes depuis deux sessions et téléverser un fichier avant de redémarrer la stack tout-en-un.

Utilisez cette fiche après un remplacement normal et après une restauration vierge. La récupération n’est validée que si les tables, les vues, les utilisateurs, les automatisations et les fichiers sont restaurés depuis la sauvegarde complète de /baserow/data. Collectez également une courte trace des ressources couvrant Postgres, Redis et les workers Celery intégrés, ainsi que le nombre de lignes, la taille des imports et le nombre d’éditeurs simultanés ; conservez-la avec la release afin que les futures évolutions de capacité soient comparées à la même charge de travail.

Incluez un incident contrôlé : envoyez une donnée inoffensive proche de la limite de ressources ou de format associée à cette frontière : l’URL publique change après la génération de liens de partage et de callback par les utilisateurs. Vérifiez que Baserow signale le problème à la bonne frontière, rétablissez la condition valide et relancez la transaction. Cela vérifie la visibilité des erreurs, et pas uniquement le succès, et empêche une interface apparemment saine de dissimuler un worker, un callback ou une connexion à la base de données défaillant.

Intégrer Baserow au cycle de vie de Dockup

Le déploiement Baserow en un clic de Dockup doit rendre les remplacements sûrs : la route continue de cibler le port 80, les secrets ne sont pas intégrés à l’image et les chemins persistants sont réutilisés par le nouveau conteneur. Le même déploiement peut s’exécuter sur le compute de Dockup ou sur une machine connectée.

Terminez le travail spécifique à l’application en confirmant l’exigence locale — suffisamment de mémoire pour Postgres, Redis, le backend et les workers intégrés —, en appliquant l’adresse publique canonique et en exécutant ce test d’acceptation : créer une base de données et une vue, importer un CSV, modifier des lignes depuis deux sessions et téléverser un fichier avant de redémarrer la stack tout-en-un. Ajoutez le résultat de la restauration au runbook avant l’arrivée des vrais utilisateurs.

Foire aux questions

De quoi Baserow a-t-il besoin pour un déploiement en production ?

Faites passer le conteneur Baserow sur le port 80 via une seule origine HTTPS. L’exigence d’exécution locale est de disposer de suffisamment de mémoire pour Postgres, Redis, le backend et les workers intégrés. Ne considérez pas Baserow comme prêt tant que vous ne pouvez pas créer une base de données et une vue, importer un CSV, modifier des lignes depuis deux sessions et téléverser un fichier avant de redémarrer la stack tout-en-un.

Quelles données Baserow faut-il inclure dans une sauvegarde ?

Rendez /baserow/data persistant et incluez l’intégralité de l’arborescence /baserow/data ainsi que des exports logiques périodiques de la base de données dans le même recovery manifest. Une restauration vierge de Baserow n’est validée que lorsque les tables, les vues, les utilisateurs, les automatisations et les fichiers sont restaurés depuis la sauvegarde complète de /baserow/data.

Baserow nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de Baserow et conservez le port 80 sur la route interne. Appliquez correctement le paramètre Baserow : définissez BASEROW_PUBLIC_URL sur l’origine externe exacte. Pour Baserow, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transmission et garantit un comportement cohérent des clients dépendant de l’origine.

Comment tester une mise à jour de Baserow ?

Restaurez l’état actuel de Baserow dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car l’image tout-en-un déplace plusieurs services simultanément : les migrations de la base de données et de l’application doivent donc être répétées à partir d’un snapshot. Conservez l’ancienne image Baserow tant que les limites de migration des données et de rollback ne sont pas clairement comprises.