Explicit local function bundling falls back to API bundling when Docker is unavailable

Open
  • Is something wrong?
#7,214 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@7ttp is already working on this.

Since Oct 28, 2026.

  • #7374 by @7ttp — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
docker, typescript
Domain
cli, devops

Research direction

Start by tracing the Edge Functions deploy path that handles --use-api=false, Docker availability checks, and API source uploads; the issue does not name source files or tests. Reproduce with a Docker stub that fails and confirm explicit local packaging stops before an API deployment request. Add regression coverage for the unavailable-Docker and precheck-race cases, while confirming default automatic fallback remains unchanged.

Written by the indexing model from the issue text.

Description

🐛 Bug open-for-contribution supabase/cli

Supabase CLI 2.121.0 attempts API source deployment with --use-api=false when its Docker check fails. The same occurs when an external Docker precheck succeeds and Docker becomes unavailable before the CLI checks it. Combining --use-api=false and --use-docker is rejected by the existing mutex.

This was reproduced with the installed macOS arm64 executable using synthetic credentials and a synthetic project, an OS sandbox denying external networking and real credential access, and a Docker stub. A supported file profile pointing to an owned loopback mock independently captured the API source-upload request. No real provider write occurred.

Expected behavior: explicit local packaging fails before an API deployment request when Docker is unavailable, while default automatic fallback remains unchanged. PR #7213 contains a narrow correction with regression tests, but was automatically closed by the contribution gate. Please triage this bug and, if appropriate, add open-for-contribution so the correction can follow the contribution workflow.

Affected area

Edge Functions / Docker

Supabase CLI version

2.121.0, Homebrew macOS arm64 binary, SHA-256 6e8be5fb2802ccdd247d3b47823c31ed8d7e792255048594ba32ee79a55208dc.

Operating system

macOS (arm64).

Command

The command below uses a generic relative profile path. It was run inside verified OS containment, with synthetic credentials and the file profile pointing exclusively to an owned loopback mock:

supabase functions deploy probe --use-api=false --project-ref abcdefghijklmnopqrst --profile ./local-profile.yaml --debug
Actual output

Machine-specific paths and timestamps have been removed from this excerpt; the observed CLI behavior is unchanged.

Loading profile from flag: ./local-profile.yaml
Using access token from env var...
Supabase CLI 2.121.0
Using profile: contained (contained.invalid)
Using access token from env var...
WARNING: Docker is not running
Uploading asset (probe): supabase/functions/probe/index.ts
HTTP POST: http://127.0.0.1:58516/v1/projects/abcdefghijklmnopqrst/functions/deploy

The mock captured the corresponding source-upload POST. Exit zero reflects the mock response, not hosted delivery. A separate all-network-denied run without profile redirection also logged an attempted Management API deploy POST, which the OS blocked.

Steps to reproduce

Use an isolated task HOME, cleared environment, synthetic access token/project and an OS sandbox denying external network access and real credential/keychain access. Establish those denial checks before entering the deployment path. Use a dependency-free probe handler with verify_jwt=false, and a supported file profile redirecting API requests to an owned loopback mock. Put a Docker stub that exits1 on PATH and invoke the command above inside containment; observe the API source-upload request despite explicit --use-api=false.

For the precheck race, make the stub return0 once for an external docker info, then1 for the CLI's subsequent check. The same fallback occurs. A synthetic project ref alone does not provide containment.

Verification limits

These reproductions establish transport selection. Real Docker packaging and actual runtime bundler-error handling were not verified by this harness. The proposed correction preserves default automatic fallback and existing targeting/JWT behavior; it adds no deployment wrapper.

Dominant language
TypeScript
Stars
2.4k
Forks
540
Avg merge
17h 3m
Merged PRs (30d)
390

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from supabase/cli

All issues in supabase/cli

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.