Moving from Supabase

This guide is for you if your app keeps its data in Supabase and you want the database, the files and the app itself in one Fortly project. Your tables, data, views, functions and triggers come across as PostgreSQL, because Fortly's database is PostgreSQL. Your app's code changes in three places: sign-in, the calls it makes through supabase-js, and anything that relied on Realtime or row-level security. Fortly has no built-in auth service, no realtime and no per-user rules on the browser key, and this page says what to do instead.

What maps to what

Before you start

You need:

• A Fortly API token in $FORTLY_TOKEN, from API tokens. Importing a database needs the account owner or an admin.
• pg_dump and psql installed locally, at the same major version as your Supabase database or newer. Supabase shows the version under Project Settings → Infrastructure. An older pg_dump refuses to dump a newer server.
• perl, which macOS and most Linux systems already have, to clean the dump.
• The AWS CLI if you use Supabase Storage.

Move your project

export FORTLY_TOKEN=fly_...

curl -X POST https://api.fortly.com/projects \
  -H "Authorization: Bearer $FORTLY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "my-app"}'

postgresql://postgres.abcdefghijklmnop:[YOUR-PASSWORD]@aws-0-us-east-1.pooler.supabase.com:5432/postgres

export SUPABASE_DB_URL='postgresql://postgres.abcdefghijklmnop:YOUR-PASSWORD@aws-0-us-east-1.pooler.supabase.com:5432/postgres'

pg_dump "$SUPABASE_DB_URL" \
  --schema=public \
  --no-owner --no-privileges \
  --no-publications --no-subscriptions \
  --inserts \
  --file=supabase.sql

cat > users.sql <<'SQL'
create table public.app_users (
  id                 uuid primary key,
  email              text,
  password_hash      text,
  email_confirmed_at timestamptz,
  created_at         timestamptz not null default now()
);
SQL

psql "$SUPABASE_DB_URL" -At -c "
  select format(
    'insert into public.app_users (id, email, password_hash, email_confirmed_at, created_at) values (%L, %L, %L, %L, %L);',
    id, email, encrypted_password, email_confirmed_at, created_at)
  from auth.users" >> users.sql

perl -0777 -pi.bak -e '
  s/^CREATE POLICY .*?;\n//gms;
  s/^ALTER TABLE .*? ENABLE ROW LEVEL SECURITY;\n//gm;
  s/^CREATE SCHEMA public;\n//gm;
  s/^COMMENT ON SCHEMA public IS .*?;\n//gm;
  s/extensions\.(uuid_generate_v4|gen_random_uuid)\(\)/gen_random_uuid()/g;
  s/REFERENCES auth\.users\(id\)/REFERENCES public.app_users(id)/g;
' supabase.sql

grep -nE '\b(auth|storage|realtime|extensions|supabase_functions|net|cron|vault|graphql)\.' supabase.sql

perl -pi -e 's#https://abcdefghijklmnop\.supabase\.co/storage/v1/object/public/#https://my-app-ada.example/_files/#g' supabase.sql

cat users.sql supabase.sql > import.sql

curl -X POST https://api.fortly.com/projects/my-app-ada/import \
  -H "Authorization: Bearer $FORTLY_TOKEN" \
  --data-binary @import.sql

{ "imported": "statements", "ran": 4182, "skipped": 41, "tables": 12 }

{ "error": "stopped after 214 statements. This one was not accepted: CREATE FUNCTION public.current_profile() RETURNS public.profiles LANGUAGE sql AS $$ select * from public.profiles where id = auth.uid() $$ (error returned from database: schema \"auth\" does not exist)" }

aws configure --profile supabase   # paste the access key and secret

aws s3 cp s3://avatars ./storage/avatars --recursive \
  --profile supabase \
  --endpoint-url https://abcdefghijklmnop.supabase.co/storage/v1/s3 \
  --region us-east-1

cd storage
find . -type f | while read -r f; do
  path="${f#./}"
  curl -sS -X POST "https://api.fortly.com/projects/my-app-ada/files/$path" \
    -H "Authorization: Bearer $FORTLY_TOKEN" \
    --data-binary "@$f"
  echo
done

curl -X POST https://api.fortly.com/projects/my-app-ada/secrets \
  -H "Authorization: Bearer $FORTLY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "STRIPE_SECRET_KEY", "value": "sk_live_..."}'

tar --exclude=node_modules --exclude=.git -czf release.tgz .

curl -X POST https://api.fortly.com/projects/my-app-ada/deploys \
  -H "Authorization: Bearer $FORTLY_TOKEN" \
  --data-binary @release.tgz

curl -X POST https://api.fortly.com/projects/my-app-ada/domains \
  -H "Authorization: Bearer $FORTLY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"host": "www.example.com"}'

curl -X POST https://api.fortly.com/projects/my-app-ada/domains/www.example.com/verify \
  -H "Authorization: Bearer $FORTLY_TOKEN"

Change your app's code

Data calls

supabase-js builds requests for Supabase's addresses and keys, so it does not work against Fortly. The filter grammar in Fortly's data API will look familiar, though:

// Before
const { data } = await supabase
  .from("posts")
  .select("id,title,author(name)")
  .eq("published", true)
  .order("created_at", { ascending: false })
  .limit(20);

// After: from the browser, with the project's publishable key
const res = await fetch(
  "https://my-app-ada.example/_data/posts?select=id,title,author(name)&published=eq.true&order=created_at.desc&limit=20",
  { headers: { Authorization: "Bearer cvp_..." } },
);
const data = await res.json();

The publishable key (cvp_…) is on the project's Data → API tab. Every table starts closed to it, and you open read, create, update and delete one table at a time. Database functions you call with supabase.rpc() can be called with POST /_data/rpc/<name> once you open them on the same tab. See The frontend data API for the full list of operators.

Server-side code can use the server data API, or a PostgreSQL driver or ORM connected with the DATABASE_URL that Fortly gives your app. See Using PostgreSQL directly.

Sign-in

Fortly does not sign your users in. You have two options:

• Sign users in from your app. Use an auth library that runs in your framework, check passwords against app_users.password_hash with bcrypt, and keep sessions in your database or in signed cookies. Your users keep their passwords.
• Use a hosted auth provider. Most of them can import bcrypt hashes, so your users keep their passwords there too.

Row-level security does not carry over

On Supabase, a policy like auth.uid() = user_id decides which rows a signed-in user can see, even when the browser talks to the database directly. Fortly has nothing equivalent. The publishable key's rules are per table and per operation, so a table you open for reading is readable in full by anyone with the key.

So any table whose rows belong to particular users stays closed to the publishable key. Your app reads it on the server, after checking who is signed in. Use the frontend data API only for data that every visitor may see or write.

Realtime

Fortly has no realtime service, and nothing pushes database changes to the browser. To show changes, poll the data API on an interval, or add a separate realtime service and publish to it from your app when it writes.

Edge Functions and cron jobs

Rewrite each Edge Function as a route in your app. Supabase runs them on Deno, so replace Deno.env.get("X") with process.env.X and check your imports. A function pg_cron called on a timer becomes a schedule that calls that route:

curl -X POST https://api.fortly.com/projects/my-app-ada/schedules \
  -H "Authorization: Bearer $FORTLY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "nightly-cleanup", "spec": "0 3 * * *", "path": "/api/cron/cleanup"}'

Schedules use five cron fields in UTC. A schedule is an ordinary request to your app, so check a shared secret in that route if it should not be public.

What's different

• One project holds everything. The app, its database, its files, its domains and its schedules live together, and deleting the project deletes all of them.
• Nothing pauses. An idle project stops after 15 minutes and starts again on the next request. There is nothing to restore by hand.
• You can't connect from your laptop. Your app gets a connection string, but there is no public address for psql or a GUI client. You load data with the import and read it with the console, the query endpoint, or an export.
• Extensions are not promised. A create extension line in your dump either works or stops the import and names itself. If you depend on PostGIS, pgvector or TimescaleDB, Fortly is not the right home for that database today.
• No auth, realtime, private files or per-row rules. Each of these is covered above.

Things to check after moving

• Row counts match. Compare a few tables on both sides:

  TerminalCopy

  curl -X POST https://api.fortly.com/projects/my-app-ada/query \
    -H "Authorization: Bearer $FORTLY_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"sql": "select count(*) from orders"}'

• Generated keys continue from the right number. The dump's setval lines are kept, so a new row should not collide with an imported one. Insert a test row in each busy table to confirm.

• An existing user can sign in with their old password through your new sign-in code.

• No table is open to the publishable key unless every row in it is meant to be public. Check the Data → API tab.

• Old storage URLs are gone. Search your data and your code for supabase.co.

• Your app no longer imports @supabase/supabase-js.

• Scheduled jobs ran. Each schedule shows its next run, and its requests appear in the project's logs.

• Keep the Supabase project until you have run on Fortly for a while. Pausing or deleting it is the last step, not the first.