Download and Build Your App#

MeDo's project code export feature lets you download your application's source code, run it locally, and — for apps with a backend — migrate it to your own Supabase project. Each download costs 300 credits.

Note: If your app is pure frontend (no backend data), you only need sections 1 to 4, then run it locally in section 9. If your app uses backend data storage, follow the full flow to rebuild the structure on your own Supabase.

#1. What Is and Isn't in Your Download

The ZIP you get from Download Code contains the structure and function code for the backend — no data, no files, no keys. This determines what the migration involves.

Note: The URL and anon key in .env point to MeDo's hosted backend. If you don't replace them, your local app still talks to the platform, not your own database. The core of migration is "rebuild the structure, then swap these two values".

#2. Download the Application Code

After the application is generated, a Download button appears above the editing interface. Click it to download the application's source code. You cannot download code while the application is still being generated. Downloading is a Pro-only feature.

The downloaded code version corresponds to the specific application version that the developer is currently editing.

If you used the visual editor to change fonts, colors, or other interface settings, preview or publish the application before downloading its code. This ensures that the downloaded package contains your latest visual changes.

#3. Unzip the Source

Unzip the downloaded package and enter the directory:

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)"

A typical structure looks like this:

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

Note: If schema.sql exists, use it (section 5, full import). If not, run supabase db push to apply the migrations.

#4. Prepare Tools

You can use VSCode, IntelliJ IDEA, or any IDE you prefer to edit the code. To run and migrate the app you need three tools: Node.js 20 or later, the Supabase CLI, and psql (the Postgres client).

On macOS with 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

Note: libpq is keg-only. If psql is still reported as "command not found", add it to your PATH with echo 'export PATH="/opt/homebrew/opt/libpq/bin:$PATH"' >> ~/.zshrc, then reopen the terminal.

On Windows, install Node.js LTS, the Supabase CLI via Scoop (scoop install supabase), and PostgreSQL (which includes psql). The commands below are identical; only the export PATH=... line is macOS-specific.

On Linux, install Node 20 or later, the Supabase CLI from the release binary, and psql via your package manager (for example sudo apt install postgresql-client).

Verify all three print a version:

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

Note: If your app is pure frontend with no backend, skip ahead to section 9 and run it locally now. The Supabase steps (5 to 8) only apply to apps with backend data storage.

#5. Create Your Own Supabase Project

#If You Don't Have a Supabase Account Yet

Go to https://supabase.com, click Start your project, and sign up with GitHub or email (free). The Free plan is plenty for migrating one MeDo app.

Note: The Free plan allows at most 2 active projects at once. If you already have 2, pause one first, otherwise you cannot create a new one.

#Create the Project

On the organization home click New project and fill in:

• Project name, for example taskflow-migrate
• Database password: click Generate a password for a strong one, and be sure to copy and save it (needed for schema import; if lost you can only reset it)
• Region: pick the one closest to your users

Click Create new project and wait one to two minutes for provisioning.

#Collect Four Credentials

Go to Project Settings and record the following. You need them in every later step.

Note: The anon key is public by design (protected by RLS) and can go into the frontend .env. The service_role / secret key is a full-access key — never put it in the frontend or commit it to git.

#6. Import the Database Structure

Use the database connection string from section 5 to load schema.sql into the new database. The string looks like 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

Note: MeDo's schema.sql uses defensive syntax (CREATE TABLE IF NOT EXISTS, storage policies wrapped in DO $$ ... EXECUTE, buckets with ON CONFLICT DO UPDATE), so importing into a brand-new project runs without conflicts.

Without schema.sql, apply the migrations through the CLI instead:

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

#Verify the 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

You can also see the migrated tables directly in the Supabase Table Editor.

#7. Deploy Edge Functions and Configure Secrets

First check whether the package has functions:

ls supabase/functions/ 2>/dev/null

If there are no functions (many apps are pure anon plus RLS, with no server-side functions), skip this section.

If there are functions, deploy them and reconfigure their 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>

Note: Function secrets are not in the source package and must be reconfigured manually: third-party API keys, and any SUPABASE_SERVICE_ROLE_KEY referenced inside functions.

#8. Migrate Data (Optional)

This step requires the connection string of the source database (MeDo's hosted Supabase). Regular users usually do not have direct source access, in which case data cannot be migrated automatically — you can only re-run the app to generate data, or ask the platform to help export it. A newly created app has no data, so you can skip this.

If you can reach the source database:

# 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

Verify that select count(*) on core tables matches between source and target.

#9. Replace .env and Run Locally

Edit .env in the project root, swapping the URL and anon key for your own project's values (collected in section 5). The variable prefix depends on the framework, so check the existing names in your .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

After editing, .env looks roughly like this:

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

Install dependencies and start the dev server:

# 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

Note: Do not use npm run dev. MeDo replaces the dev and build scripts in package.json with a placeholder echo, so they do nothing. Use npx vite instead.

Open the address shown in the terminal (for example http://127.0.0.1:5173/); the landing page should render.

#Disable Email Confirmation

A new Supabase project has email confirmation enabled by default, so after signup you would need a confirmation email before you can log in. For local testing, turn it off first: in the console go to Authentication → Sign In / Providers → Email, toggle off Confirm email, and save.

Note: Disabling confirmation (and the admin-API shortcut below) is for local testing only. Before going to production, turn Confirm email back on so real users verify their address.

The Free plan also has an email send rate limit. If you still hit email rate limit exceeded after disabling confirmation, use the service key to create a pre-confirmed user via the admin API:

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}'

#Verify That Data Lands in Your Database

In the app, sign up or log in and create a record, then query the database:

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

After login you reach the workspace, with data coming from your own Supabase.

All three tables return the corresponding records, proving the whole chain — signup, trigger-created profile, business write — hits your own Supabase.

#10. Common Pitfalls

#11. Migration Checklist

• Tools ready: supabase, psql, node 20 or later
• Download and unzip the source, confirm supabase/schema.sql exists
• Create your own Supabase project, save the database password
• Collect four credentials: URL, anon key, database connection string, service key
• Run psql -f supabase/schema.sql, verify tables, RLS, and triggers
• If functions exist, deploy them and configure secrets (otherwise skip)
• If data is needed, migrate it (only if you can reach the source database, otherwise skip)
• Replace the URL and anon key in .env
• Disable Confirm email
• Run pnpm install and npx vite, then sign up, log in, and create data
• Query the database to confirm data hits your own Supabase