Home

Supabase CLI

The Supabase CLI provides tools to develop your project locally and deploy to the Supabase Platform. The CLI is still under development, but it contains all the functionality for working with your Supabase projects and the Supabase Platform.

Global flags

Supabase CLI supports global flags for every command.

Flags

  • --debug
    Optional
    no type

    output debug logs to stderr

  • --dns-resolver <[ native | https ]>
    Optional
    no type

    lookup domain names using the specified resolver

  • --experimental
    Optional
    no type

    enable experimental features

  • -h, --help
    Optional
    no type

    help for supabase

  • --workdir <string>
    Optional
    no type

    path to a Supabase project directory

$ supabase init

Initialize configurations for Supabase local development.

A supabase/config.toml file is created in your current working directory. This configuration is specific to each local project.

You may override the directory path by specifying the SUPABASE_WORKDIR environment variable or --workdir flag.

In addition to config.toml, the supabase directory may also contain other Supabase objects, such as migrations, functions, tests, etc.

supabase init

$ supabase login

Connect the Supabase CLI to your Supabase account by logging in with your personal access token.

Your access token is stored securely in native credentials storage. If native credentials storage is unavailable, it will be written to a plain text file at ~/.supabase/access-token.

If this behavior is not desired, such as in a CI environment, you may skip login by specifying the SUPABASE_ACCESS_TOKEN environment variable in other commands.

The Supabase CLI uses the stored token to access Management APIs for projects, functions, secrets, etc.

supabase login

$ supabase start

Starts the Supabase local development stack.

Requires supabase/config.toml to be created in your current working directory by running supabase init.

All service containers are started by default. You can exclude those not needed by passing in -x flag. To exclude multiple containers, either pass in a comma separated string, such as -x gotrue,imgproxy, or specify -x flag multiple times.

It is recommended to have at least 7GB of RAM to start all services.

Health checks are automatically added to verify the started containers. Use --ignore-health-check flag to ignore these errors.

Flags

  • -x, --exclude <strings>
    Optional
    no type

    Names of containers to not start. [gotrue,realtime,storage-api,imgproxy,kong,inbucket,postgrest,pgadmin-schema-diff,migra,postgres-meta,studio,edge-runtime,logflare,vector]

  • --ignore-health-check
    Optional
    no type

    Ignore unhealthy services and exit 0

supabase start

$ supabase stop

Stops the Supabase local development stack.

Requires supabase/config.toml to be created in your current working directory by running supabase init.

All Docker resources are cleaned up by default. Use --backup flag to persist your local development data between restarts.

Flags

  • --no-backup
    Optional
    no type

    Deletes all data volumes after stopping.

supabase stop

$ supabase status

Shows status of the Supabase local development stack.

Requires the local development stack to be started by running supabase start or supabase db start.

You can export the connection parameters for initializing supabase-js locally by specifying the -o env flag. Supported parameters include JWT_SECRET, ANON_KEY, and SERVICE_ROLE_KEY.

Flags

  • -o, --output <[ env | pretty | json | toml | yaml ]>
    Optional
    no type

    Output format of status variables.

  • --override-name <strings>
    Optional
    no type

    Override specific variable names.

supabase status

$ supabase test db

Executes pgTAP tests against the local database.

Requires the local development stack to be started by running supabase start.

Runs pg_prove in a container with unit test files volume mounted from supabase/tests directory. The test file can be suffixed by either .sql or .pg extension.

Since each test is wrapped in its own transaction, it will be individually rolled back regardless of success or failure.

supabase test db

$ supabase test new

Create a new test file

Flags

  • -t, --template <[ pgtap ]>
    Optional
    no type

    Template framework to generate.

supabase test new <name> [flags]

$ supabase gen keys

Generate keys for preview branch

Flags

  • -o, --output <[ env | json | toml | yaml ]>
    Optional
    no type

    Output format of key variables.

  • --override-name <strings>
    Optional
    no type

    Override specific variable names.

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

  • --experimental
    REQUIRED
    no type

    enable experimental features

supabase gen keys [flags]

$ supabase gen types typescript

Generate types for TypeScript. Must specify one of --local, --linked, --project-id, or --db-url

Flags

  • --db-url <string>
    Optional
    no type

    Generate types from a database url.

  • --linked
    Optional
    no type

    Generate types from the linked project.

  • --local
    Optional
    no type

    Generate types from the local dev database.

  • --project-id <string>
    Optional
    no type

    Generate types from a project ID.

  • --schema <stringArray>
    Optional
    no type

    Schemas to generate types for.

supabase gen types typescript [flags]

$ supabase db dump

Dumps contents from a remote database.

Requires your local project to be linked to a remote database by running supabase link. For self-hosted databases, you can pass in the connection parameters using --db-url flag.

Runs pg_dump in a container with additional flags to exclude Supabase managed schemas. The ignored schemas include auth, stroage, and those created by extensions.

The default dump does not contain any data or custom roles. To dump those contents explicitly, specify either the --data-only and --role-only flag.

Flags

  • --data-only
    Optional
    no type

    Dumps only data records.

  • -f, --file <string>
    Optional
    no type

    File path to save the dumped contents.

  • --keep-comments
    Optional
    no type

    Keeps commented lines from pg_dump output.

  • -p, --password <string>
    Optional
    no type

    Password to your remote Postgres database.

  • --role-only
    Optional
    no type

    Dumps only cluster roles.

  • --db-url <string>
    Optional
    no type

    connect using the specified database url

supabase db dump -f supabase/schema.sql

$ supabase db push

Pushes all local migrations to a remote database.

Requires your local project to be linked to a remote database by running supabase link. For self-hosted databases, you can pass in the connection parameters using --db-url flag.

The first time this command is run, a migration history table will be created under supabase_migrations.schema_migrations. After successfully applying a migration, a new row will be inserted into the migration history table with timestamp as its unique id. Subsequent pushes will skip migrations that have already been applied.

If you need to mutate the migration history table, such as deleting existing entries or inserting new entries without actually running the migration, use the migration repair command.

Use the --dry-run flag to view the list of changes before applying.

Flags

  • --dry-run
    Optional
    no type

    Print the migrations that would be applied, but don't actually apply them.

  • -p, --password <string>
    Optional
    no type

    Password to your remote Postgres database.

  • --db-url <string>
    Optional
    no type

    connect using the specified database url

supabase db push

$ supabase db reset

Resets the local database to a clean state.

Requires the local development stack to be started by running supabase start.

Recreates the local Postgres container and applies all local migrations found in supabase/migrations directory. If test data is defined in supabase/seed.sql, it will be seeded after the migrations are run. Any other data or schema changes made during local development will be discarded.

Note that since Postgres roles are cluster level entities, those changes will persist between resets. In order to reset custom roles, you need to restart the local development stack.

Flags

  • --linked
    Optional
    no type

    Resets the linked project to current migrations.

  • --db-url <string>
    Optional
    no type

    connect using the specified database url

supabase db reset

$ supabase db diff

Diffs schema changes made to the local or remote database.

Requires the local development stack to be running when diffing against the local database. To diff against a remote or self-hosted database, specify the --linked or --db-url flag respectively.

Runs djrobstep/migra in a container to compare schema differences between the target database and a shadow database. The shadow database is created by applying migrations in local supabase/migrations directory in a separate container. Output is written to stdout by default. For convenience, you can also save the schema diff as a new migration file by passing in -f flag.

By default, all schemas in the target database are diffed. Use the --schema public,extensions flag to restrict diffing to a subset of schemas.

While the diff command is able to capture most schema changes, there are cases where it is known to fail. Currently, this could happen if you schema contains:

  • Changes to publication
  • Changes to storage buckets
  • Views with security_invoker attributes

Flags

  • -f, --file <string>
    Optional
    no type

    Saves schema diff to a new migration file.

  • --linked
    Optional
    no type

    Diffs local schema against the linked project.

  • -s, --schema <strings>
    Optional
    no type

    List of schema to include.

  • --use-migra
    Optional
    no type

    Use migra to generate schema diff.

  • --use-pgadmin
    Optional
    no type

    Use pgAdmin to generate schema diff.

  • --db-url <string>
    Optional
    no type

    connect using the specified database url

supabase db diff -f my_table

$ supabase db lint

Lints local database for schema errors.

Requires the local development stack to be running when linting against the local database. To lint against a remote or self-hosted database, specify the --linked or --db-url flag respectively.

Runs plpgsql_check extension in the local Postgres container to check for errors in all schemas. The default lint level is warning and can be raised to error via the --level flag.

To lint against specific schemas only, pass in the --schema flag.

Flags

  • --level <[ warning | error ]>
    Optional
    no type

    Error level to emit.

  • --linked
    Optional
    no type

    Lints the linked project for schema errors.

  • -s, --schema <strings>
    Optional
    no type

    List of schema to include.

  • --db-url <string>
    Optional
    no type

    connect using the specified database url

supabase db lint

$ supabase db remote commit

Pulls schema changes from a remote database and inserts a new row into the migration history table.

Requires your local project to be linked to a remote database by running supabase link. For self-hosted databases, you can pass in the connection parameters using --db-url flag.

If no entries exist in the migration history table, pg_dump will be used to capture all contents of the remote schemas you have created. After that, a new record will be inserted into the migration history table. Subsequent runs of this command will only diff schema changes against the remote database similar to db diff --linked.

Flags

  • --db-url <string>
    Optional
    no type

    connect using the specified database url

  • -p, --password <string>
    Optional
    no type

    Password to your remote Postgres database.

  • -s, --schema <strings>
    Optional
    no type

    List of schema to include.

supabase db remote commit

$ supabase migration new

Creates a new migration file locally.

A supabase/migrations directory will be created if it does not already exists in your current workdir. All schema migration files must be created in this directory following the pattern <timestamp>_<name>.sql.

Outputs from other commands like db diff may be piped to migration new <name> via stdin.

supabase migration new schema_test

$ supabase migration list

Lists migration history in both local and remote databases.

Requires your local project to be linked to a remote database by running supabase link. For self-hosted databases, you can pass in the connection parameters using --db-url flag.

Note that URL strings must be escaped according to RFC 3986.

Local migrations are stored in supabase/migrations directory while remote migrations are tracked in supabase_migrations.schema_migrations table. Only the timestamps are compared to identify any differences.

In case of discrepancies between the local and remote migration history, you can resolve them using the migration repair command.

Flags

  • --db-url <string>
    Optional
    no type

    connect using the specified database url

  • -p, --password <string>
    Optional
    no type

    Password to your remote Postgres database.

supabase migration list

$ supabase migration repair

Repairs the remote migration history table.

Requires your local project to be linked to a remote database by running supabase link.

If your local and remote migration history goes out of sync, you can repair the remote history by marking specific migrations as --status applied or --status reverted. Marking as reverted will delete an existing record from the migration history table while marking as applied will insert a new record.

For example, your migration history table may look like this after running db remote commit for the first time.

$ supabase migration list
        LOCAL      │     REMOTE     │     TIME (UTC)
  ─────────────────┼────────────────┼──────────────────────
    20230103054303 │ 20230103054303 │ 2023-01-03 05:43:03

To reset your migration history to a clean state, first delete your local migration file.

$ rm supabase/migrations/20230103054303_remote_commit.sql
$ supabase migration list
        LOCAL      │     REMOTE     │     TIME (UTC)
  ─────────────────┼────────────────┼──────────────────────
                   │ 20230103054303 │ 2023-01-03 05:43:03

Then mark the remote migration 20230103054303 as reverted.

$ supabase migration repair 20230103054303 --status reverted
Repaired migration history: 20230103054303 => reverted
$ supabase migration list
        LOCAL      │     REMOTE     │     TIME (UTC)
  ─────────────────┼────────────────┼──────────────────────

Now you can run db remote commit again to dump the remote schema as a local migration file.

Flags

  • --db-url <string>
    Optional
    no type

    connect using the specified database url

  • -p, --password <string>
    Optional
    no type

    Password to your remote Postgres database.

  • --status <[ applied | reverted ]>
    REQUIRED
    no type

    Version status to update.

supabase migration repair 20230103054303 --status reverted

$ supabase migration up

Apply pending migrations to local database

supabase migration up

$ supabase projects create

Create a project on Supabase

Flags

  • --db-password <string>
    Optional
    no type

    Database password of the project.

  • -i, --interactive
    Optional
    no type

    Enables interactive mode.

  • --org-id <string>
    Optional
    no type

    Organization ID to create the project in.

  • --plan <[ free | pro ]>
    Optional
    no type

    Select a plan that suits your needs.

  • --region <string>
    Optional
    no type

    Select a region close to you for the best performance.

supabase projects create <project name> [flags]

$ supabase projects list

List all Supabase projects the logged-in user can access.

supabase projects list

$ supabase orgs list

List all organizations the logged-in user belongs.

supabase orgs list

$ supabase functions new

Create a new Function locally

supabase functions new <Function name>

$ supabase functions download

Download the source code for a Function from the linked Supabase project.

Flags

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase functions download <Function name> [flags]

$ supabase functions serve

Serve all Functions locally

Flags

  • --env-file <string>
    Optional
    no type

    Path to an env file to be populated to the Function environment.

  • --import-map <string>
    Optional
    no type

    Path to import map file.

  • --no-verify-jwt
    Optional
    no type

    Disable JWT verification for the Function.

supabase functions serve <Function name> [flags]

$ supabase functions deploy

Deploy a Function to the linked Supabase project.

Flags

  • --import-map <string>
    Optional
    no type

    Path to import map file.

  • --no-verify-jwt
    Optional
    no type

    Disable JWT verification for the Function.

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase functions deploy <Function name> [flags]

$ supabase functions delete

Delete a Function from the linked Supabase project. This does NOT remove the Function locally.

Flags

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase functions delete <Function name> [flags]

$ supabase secrets set

Set a secret(s) to the linked Supabase project.

Flags

  • --env-file <string>
    Optional
    no type

    Read secrets from a .env file.

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase secrets set [flags] <NAME=VALUE> ...

$ supabase secrets list

List all secrets in the linked project.

Flags

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase secrets list

$ supabase secrets unset

Unset a secret(s) from the linked Supabase project.

Flags

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase secrets unset <NAME> ...

$ supabase sso

Manage SSO authentication for Supabase projects.

Flags

  • --project-ref <string>
    REQUIRED
    string

    Project ref of the Supabase project.

  • --output [ pretty | json | yaml | toml ]
    Optional
    [ pretty | json | yaml | toml ]

    Output format of the command, useful when using the CLI in scripts or CI workflows.

$ supabase sso list

List all connections to a SSO identity provider to your Supabase project.

Flags

  • --project-ref <string>
    REQUIRED
    string

    Project ref of the Supabase project.

  • --output [ pretty | json | yaml | toml ]
    Optional
    [ pretty | json | yaml | toml ]

    Output format of the command, useful when using the CLI in scripts or CI workflows.

$ supabase sso show <provider-id>

Provides the information about an established connection to an identity provider. You can use --metadata to obtain the raw SAML 2.0 Metadata XML document stored in your project's configuration.

Flags

  • --project-ref <string>
    REQUIRED
    string

    Project ref of the Supabase project.

  • --output [ pretty | json | yaml | toml ]
    Optional
    [ pretty | json | yaml | toml ]

    Output format of the command, useful when using the CLI in scripts or CI workflows.

supabase sso show 6df4d73f-bf21-405f-a084-b11adf19fea5 \
  --project-ref abcdefghijklmnopqrst

$ supabase sso add

Add and configure a new connection to a SSO identity provider to your Supabase project.

Flags

  • --project-ref <string>
    REQUIRED
    string

    Project ref of the Supabase project.

  • --output [ pretty | json | yaml | toml ]
    Optional
    [ pretty | json | yaml | toml ]

    Output format of the command, useful when using the CLI in scripts or CI workflows.

  • --type saml
    REQUIRED
    string

    Type of identity provider being added. Only SAML 2.0 supported at this time.

  • --metadata-url <URL>
    REQUIRED
    string

    A URL (typically HTTPS) that points to a SAML 2.0 Metadata XML document describing the SAML features supported by the identity provider being added. Mutually exclusive with --metadata-file.

  • --metadata-file <path to file>
    REQUIRED
    string

    A path to a file containing a SAML 2.0 Metadata XML document describing the SAML features supported by the identity provider being added. Prefer using --metadata-url if possible. Mutually exclusive with --metadata-url.

  • domains
    Optional
    string

    A comma separated list of email domains to associate with this identity provider. Used to quickly sign users in on the frontend by identifying the correct identity provider based on the email address of the user.

  • attribute-mapping-file
    Optional
    string

    A file containing a JSON document describing the attribute mappings attached to this identity provider. User information contained in the SAML assertion will be mapped according to the rules laid out in this document.

supabase sso add \
  --project-ref abcdefgijklmnopqrst \
  --type saml \
  --metadata-url 'https://...' \
  --domains company.com

$ supabase sso update <provider-id>

Update the configuration settings of a already added SSO identity provider.

Flags

  • --project-ref <string>
    REQUIRED
    string

    Project ref of the Supabase project.

  • --output [ pretty | json | yaml | toml ]
    Optional
    [ pretty | json | yaml | toml ]

    Output format of the command, useful when using the CLI in scripts or CI workflows.

  • --metadata-url <URL>
    Optional
    string

    A URL (typically HTTPS) that points to a SAML 2.0 Metadata XML document describing the SAML features supported by the identity provider being added. Mutually exclusive with --metadata-file.

  • --metadata-file <path to file>
    Optional
    string

    A path to a file containing a SAML 2.0 Metadata XML document describing the SAML features supported by the identity provider being added. Prefer using --metadata-url if possible. Mutually exclusive with --metadata-url.

  • domains
    Optional
    string

    A comma separated list of email domains to associate with this identity provider. Used to quickly sign users in on the frontend by identifying the correct identity provider based on the email address of the user. When provided all of the domains already attached to the identity provider will be replaced with this list.

  • add-domains
    Optional
    no type

    Associates these additional email domains to the existing set of domains. See --domains for a detailed explanation.

  • remove-domains
    Optional
    no type

    Removes these email domains from the existing set of domains. See --domains for a detailed explanation.

  • attribute-mapping-file
    Optional
    string

    A file containing a JSON document describing the attribute mappings attached to this identity provider. User information contained in the SAML assertion will be mapped according to the rules laid out in this document.

supabase sso update 6df4d73f-bf21-405f-a084-b11adf19fea5 \
  --project-ref abcdefghijklmnopqrst \
  --domains new-company.com,new-company.net

$ supabase sso remove <provider-id>

Remove a connection to an already added SSO identity provider. Removing the provider will prevent existing users from logging in. Please treat this command with care.

Flags

  • --project-ref <string>
    REQUIRED
    string

    Project ref of the Supabase project.

  • --output [ pretty | json | yaml | toml ]
    Optional
    [ pretty | json | yaml | toml ]

    Output format of the command, useful when using the CLI in scripts or CI workflows.

supabase sso remove 6df4d73f-bf21-405f-a084-b11adf19fea5 \
  --project-ref abcdefghijklmnopqrst

$ supabase sso info

Returns all of the important SSO information necessary for your project to be registered with a SAML 2.0 compatible identity provider.

Flags

  • --project-ref <string>
    REQUIRED
    string

    Project ref of the Supabase project.

  • --output [ pretty | json | yaml | toml ]
    Optional
    [ pretty | json | yaml | toml ]

    Output format of the command, useful when using the CLI in scripts or CI workflows.

supabase sso info --project-ref abcdefghijklmnopqrst

$ supabase domains activate

Activates the custom hostname configuration for a project.

This reconfigures your Supabase project to respond to requests on your custom hostname. After the custom hostname is activated, your project's auth services will no longer function on the Supabase-provisioned subdomain.

Flags

  • --include-raw-output
    Optional
    no type

    Include raw output (useful for debugging).

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase domains activate

$ supabase domains create

Create a custom hostname for your Supabase project.

Expects your custom hostname to have a CNAME record to your Supabase project's subdomain.

Flags

  • --custom-hostname <string>
    Optional
    no type

    The custom hostname to use for your Supabase project.

  • --include-raw-output
    Optional
    no type

    Include raw output (useful for debugging).

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase domains create [flags]

$ supabase domains get

Retrieve the custom hostname config for your project, as stored in the Supabase platform.

Flags

  • --include-raw-output
    Optional
    no type

    Include raw output (useful for debugging).

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase domains get

$ supabase domains reverify

Re-verify the custom hostname config for your project

Flags

  • --include-raw-output
    Optional
    no type

    Include raw output (useful for debugging).

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase domains reverify

$ supabase domains delete

Deletes the custom hostname config for your project

Flags

  • --include-raw-output
    Optional
    no type

    Include raw output (useful for debugging).

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase domains delete

$ supabase vanity-subdomains activate

Activate a vanity subdomain for your Supabase project.

This reconfigures your Supabase project to respond to requests on your vanity subdomain. After the vanity subdomain is activated, your project's auth services will no longer function on the {project-ref}.{supabase-domain} hostname.

Flags

  • --desired-subdomain <string>
    Optional
    no type

    The desired vanity subdomain to use for your Supabase project.

  • --experimental
    REQUIRED
    no type

    enable experimental features

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase vanity-subdomains activate [flags]

$ supabase vanity-subdomains get

Get the current vanity subdomain

Flags

  • --experimental
    REQUIRED
    no type

    enable experimental features

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase vanity-subdomains get

$ supabase vanity-subdomains check-availability

Checks if a desired subdomain is available for use

Flags

  • --desired-subdomain <string>
    Optional
    no type

    The desired vanity subdomain to use for your Supabase project.

  • --experimental
    REQUIRED
    no type

    enable experimental features

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase vanity-subdomains check-availability [flags]

$ supabase vanity-subdomains delete

Deletes the vanity subdomain for a project, and reverts to using the project ref for routing.

Flags

  • --experimental
    REQUIRED
    no type

    enable experimental features

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase vanity-subdomains delete

$ supabase network-bans

Network bans are IPs that get temporarily blocked if their traffic pattern looks abusive (e.g. multiple failed auth attempts).

The subcommands help you view the current bans, and unblock IPs if desired.

$ supabase network-bans get

Get the current network bans

Flags

  • --experimental
    REQUIRED
    no type

    enable experimental features

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase network-bans get

$ supabase network-bans remove

Remove a network ban

Flags

  • --db-unban-ip <strings>
    Optional
    no type

    IP to allow DB connections from.

  • --experimental
    REQUIRED
    no type

    enable experimental features

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase network-bans remove [flags]

$ supabase network-restrictions get

Get the current network restrictions

Flags

  • --experimental
    REQUIRED
    no type

    enable experimental features

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase network-restrictions get

$ supabase network-restrictions update

Update network restrictions

Flags

  • --bypass-cidr-checks
    Optional
    no type

    Bypass some of the CIDR validation checks.

  • --db-allow-cidr <strings>
    Optional
    no type

    CIDR to allow DB connections from.

  • --experimental
    REQUIRED
    no type

    enable experimental features

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase network-restrictions update [flags]

$ supabase ssl-enforcement get

Get the current SSL enforcement configuration

Flags

  • --experimental
    REQUIRED
    no type

    enable experimental features

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase ssl-enforcement get

$ supabase ssl-enforcement update

Update SSL enforcement configuration

Flags

  • --disable-db-ssl-enforcement
    Optional
    no type

    Whether the DB should disable SSL enforcement for all external connections.

  • --enable-db-ssl-enforcement
    Optional
    no type

    Whether the DB should enable SSL enforcement for all external connections.

  • --experimental
    REQUIRED
    no type

    enable experimental features

  • --project-ref <string>
    Optional
    no type

    Project ref of the Supabase project.

supabase ssl-enforcement update [flags]

$ supabase completion zsh

Generate the autocompletion script for the zsh shell.

If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once:

echo "autoload -U compinit; compinit" >> ~/.zshrc

To load completions in your current shell session:

source <(supabase completion zsh)

To load completions for every new session, execute once:

Linux:

supabase completion zsh > "${fpath[1]}/_supabase"

macOS:

supabase completion zsh > $(brew --prefix)/share/zsh/site-functions/_supabase

You will need to start a new shell for this setup to take effect.

Flags

  • --no-descriptions
    Optional
    no type

    disable completion descriptions

supabase completion zsh [flags]

$ supabase completion powershell

Generate the autocompletion script for powershell.

To load completions in your current shell session:

supabase completion powershell | Out-String | Invoke-Expression

To load completions for every new session, add the output of the above command to your powershell profile.

Flags

  • --no-descriptions
    Optional
    no type

    disable completion descriptions

supabase completion powershell [flags]

$ supabase completion fish

Generate the autocompletion script for the fish shell.

To load completions in your current shell session:

supabase completion fish | source

To load completions for every new session, execute once:

supabase completion fish > ~/.config/fish/completions/supabase.fish

You will need to start a new shell for this setup to take effect.

Flags

  • --no-descriptions
    Optional
    no type

    disable completion descriptions

supabase completion fish [flags]

$ supabase completion bash

Generate the autocompletion script for the bash shell.

This script depends on the 'bash-completion' package. If it is not installed already, you can install it via your OS's package manager.

To load completions in your current shell session:

source <(supabase completion bash)

To load completions for every new session, execute once:

Linux:

supabase completion bash > /etc/bash_completion.d/supabase

macOS:

supabase completion bash > $(brew --prefix)/etc/bash_completion.d/supabase

You will need to start a new shell for this setup to take effect.

Flags

  • --no-descriptions
    Optional
    no type

    disable completion descriptions

supabase completion bash