How to Migrate from Supabase to InsForge (Without Losing a Single Row)

A couple of weeks ago I told you about InsForge, the Supabase alternative that was going to change the way you work. And it resonated. Because since then, by far the most common question in the comments, in DMs, everywhere has been the same: “Edu, how do I migrate what I already have in Supabase?”

And look, I get it. A lot of you have real projects, with real users, real data. You can’t just throw everything away and start from scratch. That’s not an option.

Well, that’s exactly what we’re covering today. How to do that migration. And I promise you: it’s way simpler than it looks.

Quick context

For anyone new here, quick context.

In previous videos I explained what InsForge is: an open source backend-as-a-service with a PostgreSQL database, authentication, storage, realtime, and its own MCP so AI agents can work with it directly. Without leaving your IDE, without configuring anything manually. Genuinely wild in terms of productivity.

Then we did another video showing how to self-host it on your own server. Worth watching if you haven’t.

After those two, the question I kept getting was: “How do I migrate my Supabase?” Both cloud and self-hosted.

Here we are.

There are two ways to do it. One with the official repository the InsForge team put together. The other with an AI skill so you can do it directly from your favorite IDE. Let’s look at both.

Option 1: The official repository

What it is

There’s an official repository called supabase-to-insforge, available on GitHub. It’s not an experiment - it’s something they’ve used to migrate real projects. The docs mention they migrated 39 users, 985 database rows and 1,569 storage files, with a 99.8% success rate. Not bad.

The migration is split into three phases: authentication, database and storage. And the great thing is it’s designed to be incremental - you can stop, resume, repeat steps. Nothing will break if something fails halfway through.

What you need

Before you start, you need three things:

Node.js 20 or higher
psql (the PostgreSQL client)
Access to your Supabase project and your InsForge instance

Step 1: Clone and install

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

Step 2: Configure environment variables

cp .env.example .env

Open .env and fill in your data:

# Direct connection to your Supabase database
SUPABASE_DB_URL=postgresql://postgres:postgres@127.0.0.1:54322/postgres

# Your InsForge instance
INSFORGE_API_URL=http://localhost:7130
INSFORGE_API_KEY=<your token - see below>

Where do you get SUPABASE_DB_URL? If you’re on cloud, find it in the Supabase dashboard under Project Settings → Database → Connection string → Direct. If you’re running locally, it looks like:

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

And the INSFORGE_API_KEY? This one isn’t in an obvious place. Here’s how to get it:

Log in to your InsForge dashboard
Open DevTools with F12 and go to the Console tab
Run this:

localStorage.getItem('insforge_token')

Copy the JWT it returns and paste it into .env

Done. Your environment is configured.

Phase 1: Migrate authentication

This is the most delicate part. Get it wrong and your users can’t log in. Two commands:

npm run export:auth
npm run import:auth

The first connects to your Supabase database, exports all users from auth.users and saves them to auth-export.json. It includes user IDs, emails and password hashes.

The second takes that JSON and imports it into InsForge, preserving the same user IDs so your database relations don’t break.

And here’s something I think is particularly well thought out: passwords are preserved. Both Supabase and InsForge use bcrypt for hashing. That means your users can keep logging in with the exact same password, no reset required. If you tried to do this by hand you’d lose your mind.

Phase 2: Migrate the database

Three steps here.

Export:

npm run export:db

Exports the full schema and all data to database/supabase-dump.sql.

Transform:

npm run transform:db

This is the key step - pay attention. Supabase SQL doesn’t work directly in InsForge because of internal differences. The transform script handles several changes automatically. For example:

Supabase RLS policies use auth.uid(). In InsForge it’s just uid()
Same with auth.role() → role() and auth.email() → email()
The auth.users reference becomes _accounts in InsForge

There are two things that require manual review that the script can’t handle on its own:

auth.jwt(): if you have policies that read data directly from the JWT token, that doesn’t exist in InsForge and you’ll need to rewrite that logic using a roles table or similar.
public.users: if you have a table with that name, it collides with an internal InsForge table. You’ll need to rename it.

Import:

npm run import:db

Phase 3: Migrate storage

For files, four steps:

npm run create:buckets      # Creates buckets in InsForge replicating your Supabase ones
npm run export:storage      # Downloads all files to your machine
npm run import:storage      # Uploads them from there to InsForge
npm run update:storage-urls # Updates URLs in the database

That last command is important. It updates every database reference that was pointing to Supabase so it points to InsForge instead. No leftover URLs anywhere.

And that’s the whole process with the repo. If your environment is properly configured, the actual migration takes just a few minutes.

Option 2: The AI skill

I know perfectly well that some of you closed the video the moment you saw those steps. Not because it’s complicated, but because you just can’t be bothered. And I get it.

So here’s something extra.

If you’re using Cursor, Claude Code, Windsurf, OpenCode or any AI agent that supports skills, there’s a specific skill for running this migration guided from inside your IDE. No manually opening terminals, no wondering what command comes next. It’s called migrate-to-insforge-skill and it’s open source.

Installation is one command:

npx skills add <repository-link>

(Link is in the video description.)

During installation you choose which skills you want and whether you want them at project or global level. I go global so they’re available in any project.

From there, your agent has complete knowledge of how to do the migration. It knows what steps to follow, in what order, what SQL transformations to apply, where it can screw up and where it needs you to manually review.

The skill covers all five parts:

Authentication
Database with all SQL transformations
Storage
Edge functions if you have them
Replacing the Supabase SDK with the InsForge one in your codebase

It’s also designed with manual approval checkpoints. The agent isn’t going to go rogue and start executing things. It’ll propose what it wants to do and you decide whether to continue. So don’t worry.

What doesn’t migrate automatically

Before wrapping up, a couple of things I don’t want catching you off guard.

Realtime subscriptions: that depends on how you implemented it in your application code. Needs a manual rewrite.

Edge functions: require review because the syntax changes. In Supabase you use Deno.serve, in InsForge it’s an export default. Not complicated, but not automatic.

Active OAuth tokens: those can’t be migrated. Any user with an active session will need to log in again. Their passwords migrate fine - the active session doesn’t.

That said, don’t let it scare you. The bulk of the migration - users, data and files - is fully automatic.

Is it worth it?

I’ll tell you it is. InsForge runs smoother, has less friction on self-hosted and if you’re paying for cloud it’ll cost you less than the equivalent Supabase plan. It’s given me far less grief in production, and that’s what matters at the end of the day.

If this was useful and you want more InsForge content - like a real side-by-side comparison between Supabase and InsForge, self-hosted vs self-hosted - drop it in the comments. If there’s interest I’ll make it.

Links to the official repo and the skill are in the description. Thanks for reading and see you in the next one.

What do you think?

Leave your opinion, question or suggestion. Comments are synced with GitHub Discussions .