Aller au contenu

English version · Version Markdown, lisible par un agent · v0.3.0

Sortir de Bastide, vers Vercel, Supabase ou ailleurs

L'archive de sortie est un droit, pas une fonctionnalité d'un palier : elle est produite sans frais et sans condition, y compris pendant un litige de facturation et trente jours après résiliation. Elle ne contient aucun format propriétaire : chaque fichier s'ouvre avec un outil du domaine public, que son LISEZMOI.md nomme. Cette page produit l'archive, la vérifie, la restaure sur votre propre PostgreSQL, puis dit ce qui se rejoue chez Vercel et chez Supabase.

Ce qu'il faut avant de commencer

  • Une paire de clés RSA, que vous gardez : les secrets ne sortent jamais en clair, et l'archive est refusée sans clé publique valide, même s'il n'y a aucun secret.
  • Pendant la bêta, la production de l'archive est un geste d'exploitant (pnpm exporter-projet), qui lit la plateforme avec la configuration ordinaire de l'API. Aucune opération du registre ne la sert encore : demandez-la à l'exploitant.

1. Produire l'archive

openssl genrsa -out cle-privee.pem 3072
openssl rsa -in cle-privee.pem -pubout -out cle.pem
pnpm exporter-projet --projet <prj_…> --cle-publique cle.pem --sortie ./archive

Le code de sortie dit l'issue : 0 archive complète, 1 refus (clé absente, projet inconnu, lecture impossible), 3 archive écrite mais incomplète : les secrets omis et les avertissements sont listés, nommés, jamais passés sous silence. Le lien de téléchargement d'une archive hébergée vaut 7 jours et se reprend après interruption (plage d'octets, curl -C -).

2. Ce que l'archive contient

Neuf éléments : code/ (sources telles que déployées), database/ (schema.sql et un CSV par table), storage/ (objets, octets d'origine), auth/utilisateurs.json, config/configuration.json, secrets/secrets.json (chiffrés), logs/journaux.ndjson, MANIFEST.json (SHA-256 de chaque fichier) et LISEZMOI.md.

3. Vérifier et restaurer sur votre infrastructure

Rien de Bastide n'est nécessaire : PostgreSQL 14 ou plus, psql, jq et sha256sum. Depuis la racine de l'archive, le contrôle d'intégrité :

cd archive
jq -r '.fichiers[] | "\(.sha256)  \(.chemin)"' MANIFEST.json | sha256sum -c -

La procédure complète de restauration (schéma, chargement des tables avec les contraintes levées le temps du chargement, objets, recomptage des lignes) est le bloc sh restauration du LISEZMOI.md de l'archive : suivez-le tel quel, c'est ce que l'exercice trimestriel de restauration (pnpm exercice-restauration) exécute sur une infrastructure neuve. Si le schéma cite un rôle absent de votre PostgreSQL, psql s'arrête en nommant le rôle : créez-le (create role <nom>;) et relancez l'étape du schéma.

Les secrets se déchiffrent à part : chaque entrée porte cle_enveloppee (clé AES-256 enveloppée en RSA-OAEP SHA-256 pour votre clé publique), iv, etiquette (GCM) et chiffre, en base64. Les noms des variables sont lisibles, les valeurs ne le sont jamais dans l'archive.

4. Rejouer chez Supabase

La base restaurée est un PostgreSQL ordinaire : chargez database/schema.sql et les CSV dans le projet cible avec psql. Les objets de storage/ se remettent en seaux de votre choix. auth/utilisateurs.json se relit avec jq et s'importe dans le système d'identité de votre choix. Les écarts propres à Bastide qui jouent à la sortie : les rôles portent le nom de la base en préfixe (LIM-11), donc relisez grant et create policy du schéma avant de les rejouer ; les politiques de sécurité au niveau des lignes sont dans le schéma.

5. Rejouer chez Vercel

Le dossier code/ est un dépôt ordinaire : poussez-le vers Git et raccordez-le à Vercel. config/configuration.json et le glowsoft.json du dépôt se relisent avec jq. Aucun outil de conversion de glowsoft.json vers vercel.json n'est livré : réécrivez les redirections, réécritures et en-têtes dans vercel.json. Les variables sensibles se déchiffrent (étape 3) puis se saisissent chez Vercel.

Incompatibilités connues

  • Aucune restauration de base à partir d'une sauvegarde n'est au catalogue d'outils MCP : la sortie passe par l'archive, pas par un retour arrière de la base.
  • secrets/secrets.json est chiffré pour votre clé publique : perdre la clé privée, c'est perdre les valeurs. Un secret que la plateforme n'a pas pu ouvrir est nommé en ARCHIVE INCOMPLÈTE, jamais omis en silence (code de sortie 3).
  • Les clés historiques anon et service_role d'un projet importé (LIM-09) cessent d'être acceptées douze mois après l'import, et ne valent que chez Bastide : à la sortie, utilisez les clés de la plateforme cible.
  • Les extensions et réglages propres à Bastide ne se déplacent pas : la diffusion depuis la base du temps réel (realtime.diffuser_les_changements, LIM-08) est une fonction de Bastide, à remplacer chez la plateforme d'arrivée.
  • L'exercice de restauration par une personne extérieure à l'équipe, sur une infrastructure qui n'est pas la nôtre (EX-MIG-200), reste à mener : l'exercice automatisé règle la partie qu'une machine sait juger.

Voir aussi : Migrer depuis Vercel, Migrer depuis Supabase, Restaurer.