Migrations

Database migrations for your core product belong in your own repository and engineering workflow.

Cofounder can help turn a business requirement into a migration-ready handoff, but it is not intended to own the product database, schema, authentication, or migration implementation.

Prepare The Engineering Handoff

Ask Cofounder to capture:

the business outcome and product behavior that require the data change
the records, workflows, and customer states affected
data retention, privacy, permissions, and audit requirements
rollout, backfill, compatibility, and rollback risks
acceptance criteria and the analytics needed to verify the result

Then give the brief to the coding agent or engineering team that owns the product repository.

For example:

Turn this approved workflow into a migration implementation brief for our
product engineer. Include the required data model behavior, affected user
states, backfill and rollback risks, permissions, analytics, and acceptance
criteria. Do not change the core product repo.

Existing Managed App Workspaces

Some existing workspaces may still have a managed app repository and managed Supabase migration flow. The operational instructions below remain supported for those workspaces. They do not change the recommended boundary for new work: keep the core product database in the engineering stack you control.

What Migrations Are For

Use migrations for database schema changes in the managed app repo.

That includes changes like:

adding tables
changing columns
updating indexes or other schema-level database setup

If you are adding tables, this is the workflow to use.

In practice, have the Engineer agent work on the schema change and add the migration in the managed app repository.

Where Migrations Live

Migrations live in supabase/migrations/ in the managed app repository.

How The Workflow Works

Add the migration file in the managed app repository.
Have the Engineer request a deploy so the migration work can reach staging.
While the handoff is open, automated checks can lint the migration files.
When you approve the change and it reaches staging, the staging migration path runs automatically.
When those changes are later published to production, the production migration path runs automatically.

Staging And Production

shipping a migration to staging applies it to staging
publishing to production applies it to production

That keeps migrations lined up with the same staging-to-production flow as the managed app code. Requesting a deploy is the normal agent path to staging; workspace Publish is the path to production.

See What Cofounder Does and Engineer Agent.