Supabase CLI

repository·develop·Indexed 25 days ago

https://github.com/supabase/cli

The Supabase CLI allows developers to run the full Supabase stack locally, manage database migrations, deploy Edge Functions, and automate project workflows from the terminal. It includes tools for managing the OpenAPI specification, generating command documentation, and programmatically seeding storage buckets or migrating databases using the CLI library.

Tokens
148.4K
Snippets
215
Records
810
Agent score
81%

What's inside supabase-cli

  1. Overview of @supabase/process-compose

    develop

    @supabase/process-compose is a TypeScript service orchestrator designed to manage a dependency graph of long-running processes. It handles startup ordering, health checks, log streaming, restart policies, and graceful shutdowns.

    Key characteristics:

    • It is a pure TypeScript library; it does not include a CLI, config file parser, or HTTP server. Consumers must build their own interface on top of the provided Orchestrator service.
    • It is built on Effect V4.
    • It uses a dependency graph to determine the correct order for starting and stopping services.
  2. Manage Supabase Edge Functions

    develop
    Supabase Edge Functions are serverless, TypeScript-based functions that run on a Deno-compatible edge runtime. They allow you to execute custom server-side code (such as webhooks, custom API endpoints, or data validation) close to your users without managing traditional server infrastructure. The runtime is secure, features fast cold starts, and does not require a package manager.
  3. Understand the Supabase CLI code structure

    develop

    The Supabase CLI is organized into top-level slices under src/. The architecture separates user-facing commands from reusable shared concerns.

    Core Slices

    • commands/: The user-facing entry point. Each command owns its own parsing, handler, and tests.
    • auth/, config/, output/, runtime/, telemetry/: Reusable concern slices shared by multiple commands or flags.
    • docs/: Owns shared command documentation content and renderers.
    • cli/: The main CLI entry point.

    Shared Concern Pattern

    Shared concerns use a split between contracts and implementations to keep service definitions readable:

    • *.service.ts: Defines Effect services and public interfaces (the contract).
    • *.layer.ts: Defines live implementations and wiring (the implementation).

    Dependency Rules

    • cli/ can import from commands/, docs/, and concern slices.
    • commands/ can import from concern slices.
    • Concern slices (auth/, config/, etc.) must not import from commands/ or cli/.
    • docs/ must not import from cli/ or commands/.
    • Commands must not import another command's internals.
  4. Summary of Environments and Variable Models

    develop

    The Supabase CLI uses a unified environments model for managing configuration and secrets.

    Environments

    • development: Used for local execution (cli dev). It is not mapped to a branch. It uses .env (pulled from development) and .env.local (personal/gitignored) for local resolution.
    • preview / production: Deployed environments mapped to project branches via config.json.

    Variables and Secrets

    • Platform Variables: Implicitly available (e.g., SUPABASE_URL).
    • User Variables: Accessed via env(VAR_NAME) syntax in config.json.
    • Secrets: A specific type of variable set using the --secret flag. Secrets are never pushed from .env files; they must be set directly on the platform via cli env set --secret.
  5. Manage Supabase projects via CLI

    develop

    The supabase projects command group provides tools to programmatically manage your Supabase infrastructure. This is useful for automation scripts and repeatable environment provisioning.

    With this command group, you can:

    • List all projects within your organizations.
    • Create new projects.
    • Delete existing projects.
    • Retrieve API keys for your projects.
  6. Manage Edge Function secrets with supabase-secrets

    develop

    The supabase-secrets command group provides tools for managing environment variables and sensitive credentials for your Supabase project. These secrets are securely stored and made available as environment variables to your Edge Functions at runtime.

    You can use these tools to:

    • Set environment-specific configurations.
    • Manage sensitive credentials (like API keys or database passwords) securely.

    Secrets can be managed individually or loaded from .env files for bulk updates.

  7. Available Supabase CLI distribution channels

    develop

    The Supabase CLI is distributed through several channels to ensure cross-platform compatibility. You can install or download it via:

    • npm / npx: The primary installation path for Node.js environments.
    • Homebrew: Via the supabase/homebrew-tap.
    • Scoop: Via the supabase/scoop-bucket.
    • Linux Package Managers: .deb, .rpm, or .apk files available via GitHub Releases.
    • GitHub Releases: Platform-specific archives and checksums for direct manual download.
  8. Understand the Supabase OpenAPI Specification

    develop
    The Supabase Management APIs are defined using an OpenAPI specification. This specification serves as the single source of truth for the API structure and is used to automatically generate the Go client and associated types. You can view the latest live API documentation via the Swagger UI.
  9. How binary-first with Docker fallback works

    develop

    The resolveService helper implements a strategy to prefer native binaries but fall back to Docker if necessary. This is used by stack.start() and prefetch().

    Resolution Logic

    resolveService attempts to resolve a binary via BinaryResolver. The result is a ServiceResolution object:

    • Success: If a binary is found and extracted, it returns { type: "binary", path: string }.
    • Fallback to Docker: If BinaryNotFoundError or DownloadError occurs, it returns { type: "docker", image: string } using the appropriate Docker image for that service and version.
    • Hard Failure: If a ChecksumMismatchError occurs, the error is propagated and not replaced by Docker, as a corrupted download is treated as a security/integrity issue.
    type ServiceResolution =
      | { readonly type: "binary"; readonly path: string }
      | { readonly type: "docker"; readonly image: string };
    export const resolveService = (
      resolver: BinaryResolver["Service"],
      service: ServiceName,
      version: string,
    ): Effect.Effect<ServiceResolution, ChecksumMismatchError> =>
      resolver.resolve({ service, version }).pipe(
        Effect.map((path): ServiceResolution => ({ type: "binary", path })),
        Effect.catchTag("BinaryNotFoundError", () =>
          Effect.succeed<ServiceResolution>({
            type: "docker",
            image: dockerImageForService(service, version),
          }),
        ),
        Effect.catchTag("DownloadError", () =>
          Effect.succeed<ServiceResolution>({
            type: "docker",
            image: dockerImageForService(service, version),
          }),
        ),
      );
  10. Compare `schema` and `migrations` workflows

    develop

    The CLI distinguishes between high-level declarative schema management and low-level migration file management.

    Featureschema (Declarative)migrations (Imperative/File-level)
    Primary UseDescribing intended database shapeDirect control over raw migration files
    CapabilitiesDiffing, generation, and high-level syncManaging concrete files and application history
    Sync Verbschema push (Platform sync)migrations push (Platform sync)
    Local Verbschema apply (Local mutation)migrations apply (Local mutation)

    Use schema for the standard workflow of declaring intent and letting the CLI handle the diffing and generation. Use migrations when you need explicit, granular control over the migration files themselves.

  11. Manage service versions for local experimentation

    develop

    To experiment with different service versions in a specific git checkout without affecting the committed configuration, the linked remote cache, or the pinned baseline, create a .supabase/local-versions.json file.

    Values in .supabase/local-versions.json override stack.json but are intended to be local to that specific checkout and should typically be gitignored.

  12. How TypeScript plugins are loaded in Nx

    develop

    Nx loads .ts plugin files by using @swc-node/register as a CommonJS transpiler. For this to work, the workspace must have @swc-node/register and @swc/core installed at the root, along with a minimal tsconfig.json at the workspace root.

    If these are missing, Nx falls back to Node.js's native TypeScript type-stripping, which prevents the plugin from being extensible.

    Note: To support TypeScript 7, this workspace aliases typescript to @typescript/typescript6 for API consumers and installs TypeScript 7 as @typescript/native to provide the tsc executable.