Exporter et auto-héberger

Votre application n'est pas verrouillée sur MeDo. Vous pouvez télécharger l'intégralité de son code source et l'exécuter sur votre propre infrastructure.

#Quand le faire

• Vous devez héberger sur vos propres serveurs, pour des raisons de conformité ou de politique d'entreprise.
• Un développeur reprend le projet et veut le placer dans son propre dépôt.
• Vous voulez continuer à développer au-delà de ce que la plateforme génère pour vous.
• Vous remettez le projet à un client qui veut tout posséder.

Si aucun de ces cas ne s'applique, rester sur MeDo est plus simple : l'hébergement, le backend et les mises à jour sont gérés pour vous.

#Coût et prérequis

Chaque téléchargement coûte 300 crédits. Au-delà, l'auto-hébergement signifie que vous reprenez les parties que MeDo assurait : provisionner une base de données, déployer des fonctions, gérer les clés et héberger le frontend. Prévoyez une heure pour une première migration et attendez-vous à avoir besoin d'un terminal.

Remarque : Si votre application est un frontend pur sans données stockées, les sections 1 à 4 suffisent, puis exécutez-la localement à la section 9. Si votre application stocke des données, suivez tout le parcours pour reconstruire la structure sur votre propre projet Supabase.

#1. Ce que contient (et ne contient pas) votre téléchargement

Le ZIP obtenu via Download Code (Télécharger le code) contient le code de structure et de fonctions du backend — pas de données, pas de fichiers, pas de clés. Cela détermine ce que la migration implique.

Remarque : L'URL et la clé anon dans .env pointent vers le backend hébergé par MeDo. Si vous ne les remplacez pas, votre application locale continue de parler à la plateforme, pas à votre propre base. Le cœur de la migration est « reconstruire la structure, puis échanger ces deux valeurs ».

#2. Télécharger le code de l'application

1. Ouvrez l'application dans l'éditeur. Le téléchargement est une fonctionnalité Pro et Max et nécessite une génération terminée — attendez la fin de la génération.
2. Cliquez sur l'icône Download Code dans la barre supérieure (à gauche de votre solde de crédits). Une infobulle explique que le package inclut un README.md pour la suite du développement.
3. Cliquez sur Download Code pour confirmer. Le téléchargement coûte 300 crédits.

Vous obtenez la version que vous êtes en train d'éditer. Si vous avez changé les polices, les couleurs ou le contenu en mode Edit ou dans la vue Code, publiez d'abord pour que le package contienne ces changements.

#3. Décompresser le code source

Décompressez le package téléchargé et entrez dans le répertoire :

cd ~/Downloads
unzip -o your-app.zip -d your-app
cd your-app/app-xxxxxxxx        # enter the folder containing package.json

# verify structure
ls -la                          # should show package.json, src/, supabase/, .env
ls -la supabase/
test -f supabase/schema.sql && echo "has schema.sql (full import)" || echo "no schema.sql (use migrations)"

Une structure typique ressemble à ceci :

app-xxxxxxxx/
├── .env                    # VITE_SUPABASE_URL / VITE_SUPABASE_ANON_KEY
├── package.json
├── src/                    # frontend source
│   └── db/supabase.ts      # createClient(url, anonKey)
└── supabase/
    ├── config.toml
    ├── migrations/         # raw migration scripts
    └── schema.sql          # full structure: tables, RLS, functions, triggers, storage bucket

Remarque : Si schema.sql existe, utilisez-le (section 5, import complet). Sinon, exécutez supabase db push pour appliquer les migrations.

#4. Préparer les outils

Vous pouvez utiliser VSCode, IntelliJ IDEA ou tout IDE de votre choix pour modifier le code. Pour exécuter et migrer l'application, trois outils sont nécessaires : Node.js 20 ou plus récent, le Supabase CLI, et psql (le client Postgres).

Sur macOS avec Homebrew :

brew install node                    # Node.js 20+ (or use the installer at https://nodejs.org)
brew install supabase/tap/supabase   # Supabase CLI
brew install libpq && brew link --force libpq   # psql / pg_dump

Remarque : libpq est keg-only. Si psql est encore signalé comme « command not found », ajoutez-le à votre PATH avec echo 'export PATH="/opt/homebrew/opt/libpq/bin:$PATH"' >> ~/.zshrc, puis rouvrez le terminal.

Sous Windows, installez Node.js LTS, le Supabase CLI via Scoop (scoop install supabase), et PostgreSQL (qui inclut psql). Les commandes ci-dessous sont identiques ; seule la ligne export PATH=... est spécifique à macOS.

Sous Linux, installez Node 20 ou plus récent, le Supabase CLI depuis le binaire de release, et psql via votre gestionnaire de paquets (par exemple sudo apt install postgresql-client).

Vérifiez que les trois affichent une version :

node -v && npm -v      # node 20 or later
supabase --version     # e.g. 2.109.1
psql --version         # e.g. psql (PostgreSQL) 18.4

Remarque : Si votre application est un frontend pur sans backend, passez à la section 9 et exécutez-la localement maintenant. Les étapes Supabase (5 à 8) ne s'appliquent qu'aux applications qui stockent des données backend.

#5. Créer votre propre projet Supabase

#Si vous n'avez pas encore de compte Supabase

Allez sur https://supabase.com, cliquez sur Start your project, et inscrivez-vous avec GitHub ou un e-mail (gratuit). Le plan Free suffit largement pour migrer une application MeDo.

Remarque : Le plan Free autorise au plus 2 projets actifs à la fois. Si vous en avez déjà 2, mettez-en un en pause d'abord, sinon vous ne pourrez pas en créer un nouveau.

#Créer le projet

Sur l'accueil de l'organisation, cliquez sur New project et renseignez :

• Project name, par exemple taskflow-migrate
• Database password : cliquez sur Generate a password pour en obtenir un fort, et copiez-le bien (nécessaire pour l'import du schéma ; s'il est perdu, vous ne pourrez que le réinitialiser)
• Region : choisissez celle la plus proche de vos utilisateurs

Cliquez sur Create new project et attendez une à deux minutes le provisionnement.

#Collecter quatre identifiants

Allez dans Project Settings et notez ce qui suit. Vous en aurez besoin à chaque étape suivante.

Remarque : La clé anon est publique par conception (protégée par RLS) et peut aller dans le .env du frontend. La clé service_role / secret est une clé à accès complet — ne la mettez jamais dans le frontend ni ne la commitez dans git.

#6. Importer la structure de la base de données

Utilisez la chaîne de connexion de la section 5 pour charger schema.sql dans la nouvelle base. La chaîne ressemble à postgresql://postgres:<your-DB-password>@db.<project-ref>.supabase.co:5432/postgres.

cd ~/Downloads/your-app/app-xxxxxxxx
export PATH="/opt/homebrew/opt/libpq/bin:$PATH"

# full import (when schema.sql exists)
psql "postgresql://postgres:<DB-password>@db.<ref>.supabase.co:5432/postgres" \
  -v ON_ERROR_STOP=0 -f supabase/schema.sql

Remarque : Le schema.sql de MeDo utilise une syntaxe défensive (CREATE TABLE IF NOT EXISTS, politiques de stockage encapsulées dans DO $$ ... EXECUTE, buckets avec ON CONFLICT DO UPDATE), donc l'import dans un projet tout neuf s'exécute sans conflits.

Sans schema.sql, appliquez les migrations via le CLI à la place :

supabase login
supabase link --project-ref <your-project-ref>
supabase db push

#Vérifier l'import

DBURL="postgresql://postgres:<DB-password>@db.<ref>.supabase.co:5432/postgres"
psql "$DBURL" -c "\dt public.*"                                                   # tables
psql "$DBURL" -tc "select count(*) from pg_policies where schemaname='public';"  # RLS policy count
psql "$DBURL" -tc "select tgname from pg_trigger where tgrelid='auth.users'::regclass and not tgisinternal;"  # triggers

Vous pouvez aussi voir les tables migrées directement dans le Table Editor de Supabase.

#7. Déployer les Edge Functions et configurer les secrets

Vérifiez d'abord si le package contient des fonctions :

ls supabase/functions/ 2>/dev/null

S'il n'y a pas de fonctions (beaucoup d'applications sont du anon plus RLS, sans fonctions côté serveur), sautez cette section.

S'il y a des fonctions, déployez-les et reconfigurez leurs secrets :

# 1) deploy all functions
supabase functions deploy --project-ref <your-project-ref>
# or one by one: supabase functions deploy <function-name>

# 2) find which secrets the functions use (Deno.env.get in source)
grep -rhoE "Deno\.env\.get\(['\"][^'\"]+['\"]\)" supabase/functions | sort -u

# 3) set them one by one (values from your own services)
supabase secrets set MY_API_KEY=xxxx --project-ref <your-project-ref>
supabase secrets list --project-ref <your-project-ref>

Remarque : Les secrets des fonctions ne sont pas dans le package source et doivent être reconfigurés manuellement : clés d'API tierces, et tout SUPABASE_SERVICE_ROLE_KEY référencé dans les fonctions.

#8. Migrer les données (facultatif)

Cette étape exige la chaîne de connexion de la base source (le Supabase hébergé par MeDo). Les utilisateurs habituels n'ont généralement pas d'accès direct à la source ; dans ce cas, les données ne peuvent pas être migrées automatiquement — vous pouvez seulement relancer l'application pour générer des données, ou demander à la plateforme d'aider à l'export. Une application tout juste créée n'a pas de données, vous pouvez donc sauter cette étape.

Si vous pouvez atteindre la base source :

# data only, no structure (structure was built in section 6)
pg_dump "<source-DB-URL>" --data-only --no-owner --no-privileges --disable-triggers -Fc -f data.dump
pg_restore --data-only --disable-triggers -d "<target-DB-URL>" data.dump

Vérifiez que select count(*) sur les tables principales correspond entre source et cible.

#9. Remplacer .env et exécuter en local

Modifiez .env à la racine du projet, en remplaçant l'URL et la clé anon par les valeurs de votre propre projet (collectées à la section 5). Le préfixe des variables dépend du framework, vérifiez donc les noms existants dans votre .env :

# Vite:  VITE_SUPABASE_URL / VITE_SUPABASE_ANON_KEY  (or VITE_APP_SUPABASE_*)
# Taro:  TARO_APP_SUPABASE_URL / TARO_APP_SUPABASE_ANON_KEY
# Expo:  EXPO_PUBLIC_SUPABASE_URL / EXPO_PUBLIC_SUPABASE_ANON_KEY

Après modification, .env ressemble à peu près à ceci :

VITE_APP_ID=app-xxxxxxxx
VITE_SUPABASE_URL=https://<your-ref>.supabase.co
VITE_SUPABASE_ANON_KEY=eyJhbG...(your own project's anon key)

Installez les dépendances et démarrez le serveur de développement :

# install deps (use pnpm if the project has pnpm-workspace.yaml, else npm i)
npm i -g pnpm && pnpm install     # or npm install

# start the dev server
npx vite --host 127.0.0.1

Remarque : N'utilisez pas npm run dev. MeDo remplace les scripts dev et build de package.json par un echo factice, donc ils ne font rien. Utilisez npx vite à la place.

Ouvrez l'adresse affichée dans le terminal (par exemple http://127.0.0.1:5173/) ; la page d'accueil devrait s'afficher.

#Désactiver la confirmation par e-mail

Un nouveau projet Supabase a la confirmation par e-mail activée par défaut, donc après l'inscription il faudrait un e-mail de confirmation avant de pouvoir se connecter. Pour les tests locaux, désactivez-la d'abord : dans la console, allez dans Authentication → Sign In / Providers → Email, désactivez Confirm email, et enregistrez.

Remarque : Désactiver la confirmation (et le raccourci admin-API ci-dessous) est réservé aux tests locaux. Avant de passer en production, réactivez Confirm email pour que les vrais utilisateurs vérifient leur adresse.

Le plan Free a aussi une limite de débit d'envoi d'e-mails. Si vous voyez encore email rate limit exceeded après avoir désactivé la confirmation, utilisez la clé de service pour créer un utilisateur pré-confirmé via l'API d'administration :

curl "https://<ref>.supabase.co/auth/v1/admin/users" \
  -H "apikey: <service_key>" -H "Authorization: Bearer <service_key>" \
  -H "Content-Type: application/json" \
  -d '{"email":"user@example.com","password":"Passw0rd!","email_confirm":true}'

#Vérifier que les données arrivent dans votre base

Dans l'application, inscrivez-vous ou connectez-vous et créez un enregistrement, puis interrogez la base :

psql "$DBURL" -tc "select email from auth.users;"          # the registered user
psql "$DBURL" -tc "select username from public.profiles;"  # profile auto-created by trigger
psql "$DBURL" -tc "select name from public.projects;"      # business data you created in the app

Après connexion, vous arrivez dans l'espace de travail, avec des données provenant de votre propre Supabase.

Les trois tables renvoient les enregistrements correspondants, ce qui prouve que toute la chaîne — inscription, profil créé par déclencheur, écriture métier — atteint votre propre Supabase.

#10. Pièges courants

#11. Liste de contrôle de migration

• Outils prêts : supabase, psql, node 20 ou plus récent
• Télécharger et décompresser le code, confirmer que supabase/schema.sql existe
• Créer votre propre projet Supabase, enregistrer le mot de passe de la base
• Collecter quatre identifiants : URL, clé anon, chaîne de connexion, clé de service
• Exécuter psql -f supabase/schema.sql, vérifier les tables, RLS et déclencheurs
• S'il y a des fonctions, les déployer et configurer les secrets (sinon sauter)
• Si des données sont nécessaires, les migrer (uniquement si vous atteignez la base source, sinon sauter)
• Remplacer l'URL et la clé anon dans .env
• Désactiver Confirm email
• Exécuter pnpm install et npx vite, puis s'inscrire, se connecter et créer des données
• Interroger la base pour confirmer que les données atteignent votre propre Supabase