@motherbase/cli builds every help screen and every dispatch from a single command registry in packages/cli/src/commands. The sections below are the commands with something to explain beyond their usage line; every command at the bottom of this page is generated from that same registry, so it cannot be a subset of what the CLI ships.

Global flags

motherbase <command> [subcommand] [args] [flags]
motherbase -h
motherbase --version

--version is only read as the version flag when no command was given, because motherbase migration squash --version <v> is Supabase's own flag and has to keep working.

Connection

motherbase login [--url <consoleUrl>] [--email <email>] [--password <password>] [--token <token>]
motherbase logout [--url <consoleUrl>]
motherbase whoami
motherbase link [projectNameOrId]
motherbase unlink
motherbase status

login posts to /api/auth/sign-in/email on the Console and stores the returned token. Omit --email/--password and it prompts. With --token it stores a token directly and makes no request, which is the CI form.

link writes .motherbase/config.json in the current directory. status prints Console URL, login state, active mode, linked project, and project health.

Where admin commands go. Everything below that touches a project resolves its base URL from the link file:

The /api/admin/... paths named per section are the direct-mode form; the Console proxies the same routes.

Projects

motherbase projects list
motherbase projects create <name> [--domain <domain>]
motherbase projects start <id>
motherbase projects stop <id>
motherbase projects restart <id>
motherbase projects update <id>
motherbase projects rebuild <id>
motherbase projects delete <id> --confirm <id>
motherbase projects logs <id> [-f]
motherbase projects info <id>
motherbase projects limits <id> [--api-cpus n --api-mem mb --db-cpus n --db-mem mb --minio-cpus n --minio-mem mb]

These commands call /api/platform/* on the Platform Console. Deleting a project requires --confirm <id>. logs -f polls the snapshot endpoint every 3 seconds.

Local stack

motherbase init [dir]
motherbase start
motherbase stop
motherbase deploy
motherbase logs [service...]

These commands are local Docker Compose wrappers and do not require Console login.

init scaffolds a directory that actually starts: a docker-compose.yml whose images build from the public repository (so no checkout and no registry are needed), and a .env with secrets generated for this install. It prints the Studio URL and the first operator's credentials.

--force discards the secrets in the existing .env, which is the only copy of the key your existing data was encrypted with. Without it, existing files are kept and reported rather than replaced.

start, stop, deploy and logs refuse to run in a directory with no compose file, and name motherbase init as the fix.

Database

motherbase db tables
motherbase db sql -e "select 1"
motherbase db sql <file.sql>
motherbase db dump [file]
motherbase db restore <file> --confirm
motherbase db restore --key <remoteKey> --confirm
motherbase db backups
motherbase db backups list
motherbase db backups config
motherbase db backups config --set key=value --set key2=value2

db sql uses /api/admin/sql; projects can disable raw SQL with CONSOLE_SQL_ENABLED=false. Backups use /api/admin/backups/*.

Migrations

motherbase migration new <name>
motherbase migrations list
motherbase migrations diff
motherbase migrations get <id>
motherbase migrations create --name <name> --up <file.sql> [--down <file.sql>]
motherbase migrations apply <id>
motherbase migrations rollback <id>

migration new creates a local timestamped SQL file. migrations * uses the server-side schema migration API.

Supabase import

motherbase import --from-supabase <connectionString>   [--service-role-key <key>] [--management-token <sbp_...>]   [--preview] [--no-data] [--no-auth] [--no-storage] [--no-edge-functions] [--no-secrets]

Imports a Supabase project into the linked Motherbase project. Six sections, three credentials:

Each section is independent. A missing credential downgrades that section to a note instead of failing the import, and a failing section never takes another down. --preview is a dry run. Without --yes the CLI asks for confirmation first.

None of the three credentials is logged, written to disk, or echoed back in the summary.

See Migrate from Supabase for the full migration workflow.

Port the application code

motherbase migrate codemod <dir> [--write]

Rewrites @supabase/supabase-js to @motherbase/client and @supabase/ssr to @motherbase/ssr in every source file under <dir>, and reports the calls this SDK does not implement, with a line number and what to do instead.

Without --write nothing is touched — it prints what it would rewrite. Run it that way first.

Deliberately a text pass rather than an AST pass, so the CLI does not carry a TypeScript parser: import specifiers and method names do not need one. The cost is that a match inside a comment or a string still gets reported, which is the right direction to be wrong in for a list a human reads.

RLS

motherbase rls list
motherbase rls enable <table>
motherbase rls disable <table>
motherbase rls policy create --table <table> --name <name> --command <SELECT|INSERT|UPDATE|DELETE|ALL> [--using <expr>] [--check <expr>] [--roles anon,authenticated]
motherbase rls policy delete <table> <name>
 
motherbase rls preset <table> <preset> [--owner-column c] [--org-column c] [--org-claim c] [--deleted-column c] [--replace]
motherbase rls simulate --sql "select * from t" [--as anon|authenticated|<userId>] [--claims '{"org_id":"x"}'] [--limit n]
motherbase rls lint [--level critical|warning|info]

Policies are real PostgreSQL policies, the same objects shown in Project Studio -> Policies.

rls preset applies one of the shipped policy sets in a single step: starter, public_crud, authenticated_crud, admin_only, blocked, owner_only, org_scoped, public_read_owner_write, soft_delete. --replace drops the table's existing policies first instead of adding to them.

rls simulate runs a query as a given caller and shows what RLS actually lets through — the CLI form of the Studio's policy simulator. rls lint runs the same security and performance advisor as motherbase inspect advisor, filtered by level.

Users

motherbase users list
motherbase users get <id>
motherbase users create --email <email> --password <password> [--name <name>] [--role USER|ADMIN]
motherbase users update <id> [--email <email>] [--name <name>] [--role USER|ADMIN]
motherbase users delete <id>
motherbase users reset-password <id> [--password <password>]
motherbase users promote <id>
motherbase users demote <id>
motherbase users revoke-sessions <id>

These commands operate project auth users through /api/admin/users/*.

Storage

motherbase storage buckets list
motherbase storage buckets create <slug> [--name <name>] [--visibility public|private]
motherbase storage buckets delete <slug> [--force]
motherbase storage ls [bucket]
motherbase storage cp <local-file> <bucket[:path]> [--visibility public|private]
motherbase storage cp <fileId> <local-file>
motherbase storage rm <id>

Uploads go through /api/admin/storage/files; downloads stream /api/admin/storage/files/:id/raw. Object identity is the server file id.

Edge functions

motherbase functions list
motherbase functions get <id>
motherbase functions new <name>
motherbase functions deploy [name] [--memory <mb>] [--timeout <ms>]
motherbase functions deploy --file <file.ts> --route <route> [--name <name>]
motherbase functions pull [name]
motherbase functions serve [name]
motherbase functions delete <id>
motherbase functions invoke <route> [--body <json>]
motherbase functions logs <id>

new scaffolds functions/<name>/index.ts and, the first time, writes functions/motherbase.d.ts next to it: the declarations for the globals the runtime injects (env, context, sendMail), so an editor stops flagging them. The file is generated and never overwritten — delete it and scaffold again to refresh it.

invoke runs a deployed function as you, the operator: it looks the route up and calls POST /admin/edge-functions/:id/invoke, the same call as Studio's Run, so it needs no EDGE_INVOKE_TOKEN and works whether or not public invocation is enabled. The public /api/edge/<route> URL is for the function's own callers, and the Console proxy strips your session before forwarding there.

deploy with no argument deploys every function under the local functions/ directory; with a name, just that one. The --file form is the older single-file path and is still supported. Either way the deploy upserts by route: it patches the existing function when the route is already taken, otherwise it creates one.

pull writes deployed function source back to disk — the inverse of deploy, and the way to recover a function that was edited in Studio. serve watches local function files and redeploys on every save, which is the local development loop.

Secrets

motherbase secrets list
motherbase secrets set <NAME> <value>
motherbase secrets unset <NAME>

Secrets are injected into edge functions when EDGE_SECRETS_ENABLED=true.

API keys

motherbase keys list
motherbase keys create <NAME> [--type publishable|secret]
motherbase keys revoke <ID>

A publishable key identifies the project and is safe in a browser bundle; a secret key runs requests as service_role and bypasses row level security. --type defaults to secret. A secret key is printed once at creation and stored hashed, so it can never be shown again.

Different from secrets above: those are values an edge function reads, these are what a client presents to reach the project. See API Keys.

Realtime

motherbase realtime config
motherbase realtime config --models todo,products
motherbase realtime channels

Realtime config maps to /api/admin/realtime/config. channels lists active server-side realtime channels.

Webhooks

motherbase webhooks list
motherbase webhooks create --name <name> --url <url> --events event.a,event.b
motherbase webhooks delete <id>
motherbase webhooks test <id>

Webhooks are project admin resources under /api/admin/webhooks/*.

Cron

motherbase cron list
motherbase cron list --app
motherbase cron create --name nightly --schedule "0 3 * * *" --command "select cleanup();"
motherbase cron delete <id>
motherbase cron toggle <id> --active <true|false>

Without --app, cron commands manage pg_cron jobs through /api/admin/cron/pg/jobs. --app lists code-defined app jobs read-only.

Config and diagnostics

motherbase config list
motherbase config get <group>
motherbase config set <group> key=value [key2=value2 ...]
 
motherbase inspect logs [--limit n]
motherbase inspect stats
motherbase inspect performance
motherbase inspect requests
motherbase inspect advisor
motherbase inspect shield

Settings map to /api/admin/settings/:group. Diagnostics map to admin logs, metrics, advisor, and shield endpoints.

Codegen

motherbase gen types typescript [--schema public] [--local] [--output database.types.ts] [--check]

Generates the Database type for the SDK from the live schema:

The server owns the emitter (apps/server/services/admin/typegen); the CLI is a transport that asks GET /admin/schema/types for the rendered file. That is deliberate: re-implementing it here would drift from the Studio download and the schema tools within a release.

import type { Database } from './database.types'
const client = createClient<Database>(url, anonKey)

motherbase gen types zod [--schema public] [--local] [--output database.schemas.ts] [--check]

Same catalog, rendered as runtime zod schemas instead of types. TypeScript types vanish at runtime, so a form post, a webhook body or a row from an untyped source is any in practice and the mistake first shows up as a column constraint violation in production.

Emits <Relation>Row, <Relation>Insert and <Relation>Update per table and view, camel-cased and capitalised (order_items becomes OrderItemsRow). Optionality matches the TypeScript Insert / Update types exactly, so a value that passes the schema is a value the REST layer accepts. Enum columns become z.enum([...]); a type the emitter does not model becomes z.unknown() rather than a guess that would reject valid data.

Output is deterministic — stable order, no timestamps, LF endings — which is what makes --check usable in CI. See the SDK reference.

AI agents

motherbase mcp [--write]

Serves the linked project to an AI agent over the Model Context Protocol, on stdio. Read-only by default: schema, policies, the advisor lint, the RLS simulator, logs and generated types. --write adds apply_migration (real DDL, recorded and rollbackable) and raw SQL writes.

Authentication is the CLI's own context, so an MCP session reaches exactly what a motherbase command could. See MCP Server.

Every command

Generated from packages/cli/src/commands — the same registry motherbase --help renders — by npm run docs:cli in the backend. packages/cli/test/docs.test.js fails when the committed table no longer matches the registry, so a command added to the CLI cannot stay missing from this page.

Connection

Orgs & projects (Console)

Local self-host

Database

Resources

Codegen

AI agents

Shell

Ungrouped