Cómo migrar de Supabase a InsForge (sin perder ni un dato)

Hace un par de semanas os hablé de InsForge, la alternativa a Supabase que prometía cambiaros la forma de trabajar. Y vaya si resonó. Porque desde entonces la pregunta más repetida en comentarios, en DMs, en todas partes, ha sido siempre la misma: “Edu, ¿y cómo migro lo que ya tengo en Supabase?”

Lo entiendo perfectamente. Muchos tenéis proyectos reales, con usuarios reales, con datos reales. No podéis simplemente tirar todo a la basura y empezar desde cero. Eso no es una opción.

Pues bien, eso es exactamente lo que vamos a ver hoy. Cómo hacer esa migración. Y os lo prometo: es mucho más sencillo de lo que parece.

Contexto rápido

Para los que lleguen nuevos, contexto rápido.

En vídeos anteriores os expliqué qué es InsForge: un backend as a service open source, con base de datos PostgreSQL, autenticación, storage, realtime y su propio MCP para que los agentes de IA puedan trabajar con él directamente. Sin salir del IDE, sin configurar nada a mano. Una locura en cuanto a productividad.

Después hicimos otro vídeo enseñando cómo instalarlo en vuestro propio servidor. Muy recomendable si aún no lo has visto.

Y después de esos dos vídeos, la pregunta más repetida fue: “¿Y cómo migro mi Supabase?” Tanto cloud como self-hosted.

Aquí estamos.

Hay dos formas de hacerlo. Una con el repositorio oficial que han preparado los propios chicos de InsForge. La otra con una skill que tengo preparada para que lo hagáis directamente con vuestro agente de IA favorito. Vamos a ver las dos.

Opción 1: El repositorio oficial

Qué es

Existe un repositorio oficial llamado supabase-to-insforge, disponible en GitHub. No es un experimento. Es algo que ellos mismos han usado para migrar proyectos reales. En la documentación mencionan que migraron 39 usuarios, 985 filas de base de datos y 1.569 archivos de storage, con una tasa de éxito del 99,8%. No está mal para empezar.

La migración se divide en tres fases: autenticación, base de datos y storage. Y lo bueno es que está diseñada para ser incremental: podéis parar, retomar, repetir pasos. No vais a romper nada si algo falla a mitad.

Qué necesitáis

Antes de ponerse, necesitáis tres cosas:

Node.js 20 o superior
psql (el cliente de PostgreSQL)
Acceso a vuestro proyecto de Supabase y a vuestra instancia de InsForge

Paso 1: Clonar e instalar

git clone https://github.com/InsForge/supabase-to-insforge.git
cd supabase-to-insforge
npm install

Paso 2: Configurar las variables de entorno

cp .env.example .env

Abrid el .env y rellenadlo con estos datos:

# Conexión directa a vuestra base de datos de Supabase
SUPABASE_DB_URL=postgresql://postgres:postgres@127.0.0.1:54322/postgres

# Vuestra instancia de InsForge
INSFORGE_API_URL=http://localhost:7130
INSFORGE_API_KEY=<vuestro token - ver más abajo>

¿Dónde sacáis la SUPABASE_DB_URL? Si estáis en cloud, la encontráis en el dashboard de Supabase, en Project Settings → Database → Connection string → Direct. Ahí aparece la cadena de conexión. Si lo tenéis en local, queda algo así:

postgresql://postgres:postgres@localhost:54322/postgres

¿Y la INSFORGE_API_KEY? Aquí viene el truco. No está en un sitio obvio. Para obtenerla:

Entrad en vuestro dashboard de InsForge
Abrid DevTools con F12 y id a la pestaña Console
Ejecutad esto:

localStorage.getItem('insforge_token')

Copiad el JWT que os devuelve y pegadlo en el .env

Listo. Ya tenéis el entorno configurado.

Fase 1: Migrar la autenticación

Esta es la parte más delicada. Si no la hacéis bien, vuestros usuarios no pueden entrar. Dos comandos:

npm run export:auth
npm run import:auth

El primero conecta a vuestra base de datos de Supabase, exporta todos los usuarios de auth.users y los guarda en un archivo auth-export.json. Incluye los IDs, los emails y los hashes de contraseña.

El segundo coge ese JSON y lo importa en InsForge, preservando los mismos IDs de usuario para que las relaciones de la base de datos no se rompan.

Y aquí viene algo que me parece especialmente bien pensado: las contraseñas se conservan. Tanto Supabase como InsForge usan bcrypt para el hash. Eso significa que vuestros usuarios van a poder seguir entrando con su misma contraseña de siempre, sin tener que resetearla. Si lo hicierais a mano os podríais morir en el intento.

Fase 2: Migrar la base de datos

Aquí el proceso tiene tres pasos.

Exportar:

npm run export:db

Exporta el schema completo y todos los datos a database/supabase-dump.sql.

Transformar:

npm run transform:db

Y esto es clave, prestad atención. El SQL de Supabase no funciona directamente en InsForge porque hay diferencias internas. El script de transformación se encarga de varios cambios automáticamente. Por ejemplo:

En Supabase las políticas RLS usan auth.uid(). En InsForge es simplemente uid()
Lo mismo con auth.role() → role() y auth.email() → email()
La referencia auth.users pasa a llamarse _accounts en InsForge

Hay dos cosas que requieren revisión manual y que el script no puede hacer solo:

auth.jwt(): si tenéis políticas que leen datos directamente del token JWT, eso no existe en InsForge y hay que reescribir esa lógica usando una tabla de roles o similar.
public.users: si tenéis una tabla con ese nombre, colisiona con una tabla interna de InsForge. Hay que renombrarla.

Importar:

npm run import:db

Fase 3: Migrar el storage

Para los archivos, el proceso tiene cuatro pasos:

npm run create:buckets      # Crea los buckets en InsForge replicando los de Supabase
npm run export:storage      # Descarga todos los archivos a vuestra máquina
npm run import:storage      # Los sube desde ahí a InsForge
npm run update:storage-urls # Actualiza las URLs en la base de datos

Ese último comando es importante. Actualiza todas las referencias en base de datos que apuntaban a Supabase para que apunten a InsForge. Así os aseguráis de que no queda ninguna URL antigua en ningún sitio.

Y eso es todo el proceso con el repo. Si tenéis el entorno configurado correctamente, la migración en sí no lleva más de unos minutos.

Opción 2: La skill de IA

Sé perfectamente que hay gente que con solo ver los pasos anteriores ya ha cerrado el vídeo. No por complicado, sino porque les da pereza. Y lo entiendo.

Así que tengo algo más.

Si estáis usando Cursor, Claude Code, Windsurf, OpenCode o cualquier agente de IA con soporte de skills, existe una skill específica para hacer esta migración guiada directamente desde vuestro IDE. Sin abrir terminales manualmente, sin buscar qué comando toca ahora. Se llama migrate-to-insforge-skill y es código abierto.

La instalación es un comando:

npx skills add <enlace-del-repositorio>

(Os dejo el enlace del repositorio en la descripción del vídeo.)

Durante la instalación elegís qué skills queréis y si las queréis a nivel de proyecto o global. Yo las pongo global para tenerlas disponibles en cualquier proyecto.

Y a partir de ahí, vuestro agente tiene el conocimiento completo de cómo hacer la migración. Sabe qué pasos hay que seguir, en qué orden, qué transformaciones hay que aplicar al SQL, dónde puede meter la pata y dónde necesita que vosotros reviséis manualmente.

La skill cubre las cinco partes:

Autenticación
Base de datos con todas las transformaciones SQL
Storage
Edge functions si las tenéis
Sustitución del SDK de Supabase por el de InsForge en vuestro código

Además, está diseñada con puntos de aprobación manual. El agente no se va a poner a ejecutar cosas a lo loco. Os va a ir proponiendo qué quiere hacer y vosotros decidís si seguir adelante o no. Tranquilos.

Cosas que no se migran automáticamente

Antes de terminar, un par de cosas que no quiero que os pille por sorpresa.

Las suscripciones de realtime: eso depende de cómo lo tengáis implementado en el código de vuestra aplicación. Hay que reescribirlo a mano.

Las edge functions: requieren revisión porque la sintaxis cambia. En Supabase usáis Deno.serve, en InsForge es un export default. No es complicado, pero no es automático.

Los tokens OAuth activos: esos no se pueden migrar. Cualquier usuario que tenga una sesión activa va a tener que volver a autenticarse. Sus contraseñas sí se migran, pero la sesión activa no.

Dicho esto, que no os asuste. El grueso de la migración - usuarios, datos y archivos - es completamente automático.

¿Vale la pena?

Os digo yo que sí. InsForge va más fino, tiene menos fricción en el self-hosted y si usáis el cloud de pago os va a salir más barato que el Supabase equivalente. A mí me ha dado mucho menos guerra en producción, y eso al final es lo que importa.

Si el vídeo os ha resultado útil y queréis que haga más contenido de InsForge - por ejemplo una comparativa real en tabla entre Supabase e InsForge, self-hosted contra self-hosted - ponedlo en los comentarios. Si veo que hay interés lo hago.

Los enlaces del repo oficial y de la skill los tenéis en la descripción. Muchas gracias por leer y nos vemos en el siguiente.

¿Qué te ha parecido?

Déjame tu opinión, pregunta o sugerencia. Los comentarios se sincronizan con GitHub Discussions .