Migration Supabase → Kuunda Cloud

Auth, SDK, cutover. Export SQL et assistant console : Importer vers Kuunda Cloud (schema.sql + data.sql).

1. Vue d’ensemble

Assistant d’import : Projet → Réglages → Import données (https://app.kuunda-cloud.com).

Éditeur SQL (schéma projet)

L’éditeur SQL et POST /migrate s’exécutent dans le schéma projet proj_…, pas dans public — comme tout dump Postgres (schéma source public). L’assistant d’import réécrit le schéma ; coller un script non adapté dans l’éditeur échoue souvent.

Exemple compatible éditeur

CREATE OR REPLACE FUNCTION ensure_user_profile(
  p_email text DEFAULT NULL
)
RETURNS void
LANGUAGE plpgsql
SECURITY DEFINER
AS $$
DECLARE
  v_uid uuid := auth.uid();
BEGIN
  IF v_uid IS NULL THEN RAISE EXCEPTION 'Not authenticated'; END IF;
  INSERT INTO profiles (id, email)
  VALUES (
    v_uid,
    COALESCE(NULLIF(TRIM(p_email), ''), COALESCE(auth.email(), ''))
  )
  ON CONFLICT (id) DO NOTHING;
END;
$$;
GRANT EXECUTE ON FUNCTION ensure_user_profile(text) TO authenticated;

2. Prérequis

Sur votre PC : terminal (PowerShell ou bash) et client PostgreSQL avec pg_dump.

Sur Supabase : mot de passe de la base (bouton Connect ou Settings → Database).

Sur Kuunda : compte sur https://app.kuunda-cloud.com/register.

Au-delà : découper les exports et répéter les imports.

3. Inventaire avant migration

4. Créer le projet Kuunda

1. Console Kuunda → Nouveau projet
2. Réglages → API — noter :
   • URL : https://xxxxxxxx.kuunda-cloud.com
   • Clé anon : kuunda_anon_…
   • Clé service_role : kuunda_service_… (serveur uniquement)
   • Schéma tenant : proj_ + 32 caractères hex

5. Configurer Auth (avant l’import des users)

Sur Supabase

Authentication → URL Configuration (Site URL, Redirect URLs) et Providers (Client ID / Secret OAuth).

Sur Kuunda

Auth → Providers : reprendre les mêmes URLs, activer les mêmes providers, enregistrer la nouvelle URI de callback affichée dans Kuunda.

Production SaaS : https://api.kuunda-cloud.com/auth/v1/callback. Mettre à jour chez Google / Apple. Conserver l’URI Supabase tant que le cutover n’est pas validé. Détail : Connexion Google (OAuth).

6. Exporter la base Supabase

Commandes, identifiants (URL / URI / mot de passe) et où les coller : page Import. Méthode : schema.sql puis data.sql via pg_dump sur l’hôte direct db.{ref}.supabase.co (pas le dump tout-en-un, pas le pooler transactionnel port 6543).

7. Importer dans Kuunda

URL : https://app.kuunda-cloud.com/{ref}/settings/import

Étape 1 — Source

1. Carte Export BaaS (schéma public)
2. Coller l’URI Postgres Supabase (optionnel, pour le comptage)
3. Schéma source : public
4. Analyser la source (comptage)

Étape 2 — Importer les comptes

Après schema.sql, étape Source → Importer auth.users

Les utilisateurs devront se reconnecter. Au premier login OAuth, Kuunda lie le compte par email.

Étape 3 — Importer Storage

Après data.sql, cliquer Importer Storage. Sans URL + clé : buckets vides seulement.

Étape 4 — Appliquer le SQL

Ordre : schema.sql → auth.users → data.sql → Storage. Détail des champs : page Import.

Avant le schéma : extensions requises (ex. pgcrypto, déjà CORE) via Database → Extensions.

1. Étape Script : uploader schema.sql
2. Transformer → proj_…
3. Appliquer sur Kuunda
4. Revenir à Source → Importer auth.users
5. Répéter Script / Transformer / Appliquer avec data.sql
6. Source → Importer Storage
7. Rapport source ↔ Kuunda — comptages Source = Kuunda

Migré : tables, RLS (auth.uid()), fonctions, triggers, vues, sync Realtime. Ignoré dans le SQL : FK vers auth.users / storage.*, rôles Supabase, COMMENT ON SCHEMA, event triggers au niveau cluster (CREATE EVENT TRIGGER), CREATE EXTENSION bloquées (installer via l’UI Extensions).

Dépannage import SQL

8. Realtime

L’import ajoute les tables à la publication Realtime. Si des tables manquent : Console → Realtime → Synchroniser la publication.

9. Edge Functions, cron, secrets

10. Adapter l’application

Variables d’environnement

SDK

import { createClient } from '@kuunda/kuunda-js';

const kuunda = createClient(
  process.env.NEXT_PUBLIC_KUUNDA_URL!,
  process.env.NEXT_PUBLIC_KUUNDA_ANON_KEY!,
  {
    dbSchema: 'proj_uuid32hexsanstirets',
    projectRef: 'abcdef12',
  }
);

Points clés

• Clé anon → header apikey uniquement, pas en Authorization: Bearer
• Bearer = JWT de session Auth (posé par le SDK après login)
• OAuth → @kuunda/kuunda-js + projectRef (provider: 'google' / github / …). Sans SDK : custom:proj-{ref}-google (tirets), pas provider=google.
• Données RLS → charger après connexion
• Storage → mêmes noms de buckets qu’avant

Compatibilité API

Différences SDK Auth

// getSession — synchrone
const session = kuunda.auth.getSession();

// getUser
const { data: user, error } = await kuunda.auth.getUser();

// onAuthStateChange — un seul argument
kuunda.auth.onAuthStateChange(({ event, session }) => { … });

11. Cutover production

1. Valider import DB (rapport comptage OK)
2. Tester login email + OAuth (UUID identique pour users importés)
3. Tester Storage et RLS
4. Déployer l’app avec @kuunda/kuunda-js
5. Ajouter callback OAuth Kuunda (conserver Supabase pour rollback)
6. Maintenance : stopper écritures Supabase, import delta si besoin
7. Basculer DNS / variables vers Kuunda

Import delta : ré-exporter les tables modifiées ou migrations à distance (POST /api/projects/{ref8}/migrate/service-role).

12. Validation finale

13. Ordre des opérations

1. Créer projet Kuunda + noter ref, schéma, clés API
2. Configurer Auth (URLs + providers OAuth)
3. Installer les extensions PostgreSQL requises (pgcrypto, etc.)
4. Exporter Supabase → schema.sql + data.sql
5. Kuunda Import : analyser la source
6. Transformer + Appliquer schema.sql
7. Importer auth.users
8. Transformer + Appliquer data.sql
9. Importer Storage
10. Rapport source ↔ Kuunda
11. Sync Realtime si besoin
12. Redéployer Edge Functions + secrets
13. Adapter l’app → @kuunda/kuunda-js
14. Tests complets
15. Cutover production

14. Ce qui ne migre pas automatiquement

Ouvrir la console