Budibase sur Google Cloud Run

Budibase est une plateforme low-code open source permettant de créer des outils internes, des applications métier et des workflows à partir de vos données. Ce module déploie Budibase sur Cloud Run v2 en s'appuyant sur le socle App_CloudRun, qui provisionne et gère l'infrastructure Google Cloud partagée.

Ce guide se concentre sur les services cloud utilisés par Budibase et sur la manière de les explorer et de les exploiter depuis la console Google Cloud et la ligne de commande. Pour les mécanismes communs à toutes les applications Cloud Run — identité du service, entrée et équilibrage de charge, mise à l'échelle et concurrence, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, sauvegardes et cycle de vie du déploiement — reportez-vous au guide du socle App_CloudRun plutôt que de les répéter ici.

1. Vue d'ensemble

Budibase s'exécute sous la forme d'un unique conteneur tout-en-un sur Cloud Run v2. L'image officielle budibase/budibase regroupe CouchDB + MinIO + Redis ainsi que les applications/le worker/le proxy de Budibase, et sert le HTTP sur le port 80 — il n'y a aucune base de données gérée externe. Le déploiement assemble un ensemble ciblé de services Google Cloud :

Fonctionnalité	Service Google Cloud	Remarques
Calcul	Cloud Run v2	Un seul conteneur tout-en-un, 4 vCPU / 8 GiB par défaut ; s'exécute en une seule instance (min = max = 1)
Base de données	Aucune (CouchDB intégré)	`database_type = "NONE"` — CouchDB, MinIO et Redis s'exécutent tous dans le conteneur
Stockage d'objets	Cloud Storage	Un bucket de données provisionné automatiquement ; le stockage d'éléments propre à Budibase est le MinIO intégré
Cache et file d'attente	Redis intégré	S'exécute dans le conteneur sur l'interface loopback ; `enable_redis` est désactivé par défaut
Secrets	Secret Manager	Sept identifiants internes générés automatiquement, injectés comme variables d'environnement secrètes du service
Entrée	URL Cloud Run / Cloud Load Balancing	URL `run.app` par défaut ; équilibreur de charge HTTPS externe + domaine personnalisé en option

Valeurs par défaut judicieuses à connaître d'emblée :

Cloud Run est éphémère / réservé à la démonstration pour Budibase. Tout l'état (documents CouchDB
- objets MinIO) réside dans le chemin /data du conteneur, et Cloud Run ne dispose d'aucun disque local durable — un redémarrage ou une nouvelle révision fait perdre le magasin de données. Pour un déploiement persistant, utilisez la variante GKE, qui monte un PVC en mode bloc sur /data.
S'exécute en une seule instance. min_instance_count = 1 et max_instance_count = 1. Le conteneur tout-en-un conserve tout son état localement ; plusieurs réplicas ne partageraient donc pas les données (split-brain). La mise à l'échelle à zéro ferait perdre le magasin de données en cours, d'où un minimum de 1.
cpu_always_allocated = true. Le CPU est alloué en permanence afin que les processus d'arrière-plan CouchDB/MinIO/Redis intégrés continuent de tourner entre les requêtes ; laissez-le à true avec min_instance_count >= 1.
Sept identifiants internes sont générés automatiquement et stockés dans Secret Manager (INTERNAL_API_KEY, JWT_SECRET, MINIO_ACCESS_KEY, MINIO_SECRET_KEY, API_ENCRYPTION_KEY, REDIS_PASSWORD, COUCH_DB_PASSWORD). Ils ne doivent jamais faire l'objet d'une rotation après le premier démarrage — les données de /data sont chiffrées avec eux et deviennent illisibles s'ils changent.
Le port 80 est fixe. Le proxy nginx de l'image tout-en-un sert l'ensemble de l'application sur le port 80 ; container_port et les sondes sont donc fixés à 80.
Aucune base de données externe ni job db-init. Budibase provisionne lui-même CouchDB et MinIO au premier démarrage ; enable_cloudsql_volume et database_type valent par défaut désactivé/NONE.
Entrée publique par défaut. ingress_settings = "all", de sorte que l'application est accessible à son URL run.app ; l'activation d'IAP place la connexion Google devant elle.

2. Services Google Cloud et comment les explorer

Toutes les commandes supposent que PROJECT et REGION sont définis. Les noms des services et des ressources sont indiqués dans les sorties du déploiement.

A. Cloud Run — le service Budibase

Budibase s'exécute en tant que service Cloud Run v2. Comme il conserve tout son état localement, il s'exécute en une seule instance (min = max = 1) ; chaque déploiement crée une révision immuable.

Console : Cloud Run → sélectionnez le service pour consulter les révisions, le trafic, les journaux et les métriques.

CLI :

gcloud run services list --project "$PROJECT" --region "$REGION"
gcloud run services describe <service-name> --project "$PROJECT" --region "$REGION"
gcloud run revisions list --service <service-name> --project "$PROJECT" --region "$REGION"

Consultez App_CloudRun pour la mise à l'échelle, la concurrence, l'environnement d'exécution et la répartition du trafic.

B. Magasin de données (CouchDB + MinIO intégrés)

Il n'y a aucune instance Cloud SQL — database_type = "NONE". Le magasin de documents CouchDB et le magasin d'objets MinIO de Budibase s'exécutent tous deux dans le conteneur et persistent dans /data. Sur Cloud Run, ce répertoire se trouve sur le système de fichiers éphémère du conteneur ; il ne survit donc pas à un redémarrage. Inspectez les services intégrés via les variables d'environnement et les journaux du conteneur plutôt que via une console de base de données gérée :

CLI :

# Confirm database_type=NONE and the bundled-service env in the running revision:
gcloud run services describe <service-name> --region "$REGION" \
  --format='value(spec.template.spec.containers[0].env)'

Pour un magasin de données durable, utilisez la variante GKE (PVC en mode bloc sur /data).

C. Cloud Storage

Un bucket Cloud Storage dédié (suffixe de nom storage) est provisionné automatiquement. Le stockage d'éléments et de pièces jointes propre à Budibase est le MinIO intégré ; ce bucket GCS est disponible pour l'intégration du stockage au niveau du socle.

Console : Cloud Storage → Buckets.

CLI :

gcloud storage buckets list --project "$PROJECT"
gcloud storage ls gs://<data-bucket>/        # bucket name is in the Outputs

Consultez App_CloudRun pour les options GCS Fuse et CMEK.

D. Redis (intégré)

Redis s'exécute dans le conteneur tout-en-un sur l'interface loopback et s'authentifie avec le REDIS_PASSWORD généré automatiquement. enable_redis est désactivé par défaut — n'activez pas de Redis externe sauf si vous externalisez délibérément le cache.

CLI :

# Verify the bundled Redis password secret is wired into the revision:
gcloud run services describe <service-name> --region "$REGION" \
  --format='value(spec.template.spec.containers[0].env)' | tr ',' '\n' | grep -i redis

E. Secret Manager

Sept identifiants internes sont générés automatiquement et stockés dans Secret Manager, puis injectés comme variables d'environnement secrètes du service : INTERNAL_API_KEY, JWT_SECRET, MINIO_ACCESS_KEY, MINIO_SECRET_KEY, API_ENCRYPTION_KEY, REDIS_PASSWORD et COUCH_DB_PASSWORD. Ils ne doivent jamais faire l'objet d'une rotation après le premier démarrage.

Console : Security → Secret Manager.

CLI :

gcloud secrets list --project "$PROJECT" --filter="name~budibase"
gcloud secrets versions access latest --secret=<secret-name> --project "$PROJECT"

Consultez App_CloudRun pour les détails de l'injection et Budibase_Common pour ce que protège chaque secret.

F. Réseau et entrée

Le service est accessible par défaut à son URL run.app. Un équilibreur de charge HTTPS externe avec un domaine personnalisé, Cloud CDN et Cloud Armor peut y être ajouté ; les paramètres d'entrée et la sortie VPC contrôlent la connectivité.

Console : Cloud Run (URL du service) ; Network services → Load balancing.

CLI :

gcloud run services describe <service-name> --region "$REGION" --format='value(status.url)'
gcloud compute addresses list --project "$PROJECT"

Consultez App_CloudRun.

G. Cloud Logging et Monitoring

Les journaux du conteneur sont envoyés vers Cloud Logging ; les métriques Cloud Run vers Cloud Monitoring, avec des tests de disponibilité et des règles d'alerte en option.

Console : Logging → Logs Explorer ; Monitoring → Dashboards / Alerting.

CLI :

gcloud run services logs read <service-name> --project "$PROJECT" --region "$REGION" --limit 50

3. Comportement de l'application Budibase

Aucune initialisation de base de données externe. Avec database_type = "NONE", il n'y a pas de job db-init. Budibase provisionne lui-même ses CouchDB et MinIO intégrés au premier démarrage dans le conteneur. Seuls les initialization_jobs fournis par l'utilisateur sont pris en compte.
L'état réside dans /data — et Cloud Run ne le conserve pas. Les documents CouchDB et les objets MinIO sont écrits dans /data sur le système de fichiers éphémère du conteneur. Tout redémarrage ou nouvelle révision repart d'un magasin vide ; considérez donc un déploiement Budibase sur Cloud Run comme éphémère/réservé à la démonstration et utilisez la variante GKE pour tout ce que vous devez conserver.
Les identifiants internes sont immuables après le premier démarrage. Les sept secrets générés chiffrent les données de /data. Modifier API_ENCRYPTION_KEY corrompt toutes les données chiffrées stockées ; modifier JWT_SECRET invalide toutes les sessions ; modifier les identifiants MinIO ou CouchDB rompt l'accès aux magasins d'objets/de documents. N'effectuez de rotation que lors d'une réinitialisation planifiée.
Configuration au premier lancement. Budibase auto-hébergé est livré sans compte administrateur par défaut. Ouvrez l'URL du service après le déploiement et créez l'administrateur initial (e-mail + mot de passe) via l'écran de configuration avant toute utilisation.
Chemin de santé. La sonde de démarrage est en TCP sur le port 80 (et non en HTTP) : nginx se lie au port en quelques secondes mais renvoie 502 tant que les services amont CouchDB/MinIO/application intégrés n'ont pas fini de démarrer ; un contrôle HTTP sur / échouerait donc pendant toute la fenêtre de démarrage des services amont — le TCP réussit dès que nginx se lie au port, ce qui permet à la révision de passer à l'état Ready pendant que les services amont terminent en arrière-plan (délai initial de 30 secondes, fenêtre de 40 tentatives à une période de 15 secondes, ~10 minutes au total). Les sondes de vivacité et de disponibilité sont en HTTP sur la racine non authentifiée / ; la sonde de vivacité utilise un délai initial de 240 secondes pour franchir la fenêtre post-démarrage pendant laquelle / renvoie encore 502.
Instance unique uniquement. Conservez min_instance_count = max_instance_count = 1 ; le magasin de données est local au conteneur et ne peut pas être partagé entre réplicas.

Vérifier la révision en cours d'exécution :

gcloud run services describe <service-name> --region "$REGION" --project "$PROJECT" \
  --format='value(status.url)'
gcloud run jobs list --project "$PROJECT" --region "$REGION"   # only user-supplied init jobs

4. Variables de configuration

Les variables sont regroupées exactement comme sur la plateforme de déploiement. Seuls les paramètres propres à Budibase ou notables pour lui sont listés ; toutes les autres entrées sont héritées d'App_CloudRun avec leur comportement standard.