<!-- ccr-slack-attribution --> _Requested by **Ivan Vasilov** · [Slack thread](https://supabase.slack.com/archives/C063LNYJJKS/p1787058646458219?thread_ts=1787058646.458219&cid=C063LNYJJKS)_ **Before:** the root `package.json` pins the Supabase CLI at `supabase: ^2.76.10`, and `pnpm-lock.yaml` resolves it to `2.76.14`. **After:** it pins `supabase: ^2.114.0`. This bumps the Supabase CLI that `pnpm run e2e:setup:cli` and `pnpm run setup:cli` shell out to, so local dev and the E2E workflows boot the local stack with a CLI from this month instead of one from ~38 minor releases ago. **How:** a one-line version change to the `supabase` devDependency in the root `package.json`. Nothing else in the repo changes — no workflow, config, or test changes. ### ⚠️ This PR is incomplete: `pnpm-lock.yaml` still needs regenerating `pnpm-lock.yaml` is **not** updated in this PR, so `pnpm install --frozen-lockfile` will fail until someone runs: ```bash pnpm install --lockfile-only ``` and pushes the result to this branch. The lockfile could not be regenerated in the environment this PR was authored in: pnpm re-resolves `apps/studio`'s `"@std/path": "npm:@jsr/std__path@^1.0.8"` on every install, and `npm.jsr.io` is not reachable from there (`ERR_PNPM_FETCH_403`). Treat this PR as needing one extra commit before it can go green. ### Why `^2.114.0` and not `^2.115.0` `2.115.0` is the current `latest` on npm, but it was published only hours ago, and `pnpm-workspace.yaml` sets `minimumReleaseAge: 4320` (3 days) with `supabase` not in `minimumReleaseAgeExclude`. Pinning `2.115.0` today would fail the repo's own supply-chain check. `2.114.0` (2026-08-12) is the newest release that satisfies that policy. ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Dependency bump. **Speculative** — this is an experiment, not a confirmed fix. ## What is the current behavior? The `Selfhosted Studio E2E Tests` workflow has been failing on `master` at the `Start supabase` step. Recent runs: - https://github.com/supabase/supabase/actions/runs/32092940311 - https://github.com/supabase/supabase/actions/runs/32131961447 In the Slack thread, Ivan Vasilov suggested trying a newer CLI and Alaister Young endorsed giving it a go. ## What is the new behavior? The workflow runs `supabase start` with CLI 2.114.0 instead of 2.76.14. The question this PR is trying to answer is simply **"does a newer CLI help this flake?"** It is not a diagnosis and not a claimed fix. If CI still fails at `Start supabase` on this branch, the bump can be kept or dropped on its own merits and the investigation continues elsewhere. ## Additional context **Verification status:** none locally. The bump was not exercised locally — this repo checkout has no `node_modules` (see the lockfile note above), so `pnpm typecheck`, `pnpm lint`, and `pnpm test:studio` were not run, and neither was `supabase start`. CI on this PR is the only signal. **Call-site compatibility check.** CLI 2.99/2.100 moved to a new TypeScript shell with a stricter argument parser: command-specific flags must now come *after* the subcommand. Both call sites in the root `package.json` already use that order, so no script changes are needed: ``` supabase stop --all --no-backup --workdir ./e2e/studio supabase start --exclude studio,mailpit --workdir ./e2e/studio ``` **Changelog entries between 2.76.14 and 2.114.0 that touch `supabase start` or local config.** Listed so reviewers know what changed in the range — **not** as a claim about what is failing in CI: - **2.112.0** — `supabase start` no longer hangs when analytics migrations fail; the analytics container exits and retries instead of booting against an unmigrated database ([#6093](https://github.com/supabase/cli/pull/6093)). - **2.112.0** — `supabase start` reuses existing volumes instead of failing when they already exist ([#6037](https://github.com/supabase/cli/pull/6037)); Kong reloads after `supabase db reset` ([#6017](https://github.com/supabase/cli/pull/6017)); custom auth email templates survive `db reset` ([#6065](https://github.com/supabase/cli/pull/6065)); `supabase start` works on SELinux-enforcing hosts ([#6000](https://github.com/supabase/cli/pull/6000)). - **2.106.0 — behavior change worth watching.** `[api].auto_expose_new_tables` now resolves to `false` when unset, and local start/reset revokes default Data API privileges for newly created `public` tables, sequences, and functions ([#5524](https://github.com/supabase/cli/pull/5524)). Neither `supabase/config.toml` nor `e2e/studio/supabase/config.toml` sets this key, so this default applies. If E2E specs create `public` objects and then read them through the Data API, they may need explicit `GRANT`s (the deprecated escape hatch is `auto_expose_new_tables = true`). - **2.106.0** — when the CLI detects a coding-agent environment, or `--agent yes` is passed, commands default to JSON output ([#5532](https://github.com/supabase/cli/pull/5532)). `e2e:setup:cli` already passes `--output json` to `supabase status` explicitly, so this should be a no-op here. - **2.100.0** — stricter flag ordering, covered above. - **2.112.0** — `functions deploy` no longer forwards `NPM_AUTH_TOKEN` into Docker bundling ([#6005](https://github.com/supabase/cli/pull/6005)). Not used by these workflows. - **2.107.0** — pg-delta is the default schema diff engine for `db diff` / `db pull` on new projects ([#5511](https://github.com/supabase/cli/pull/5511)). - Many bundled Docker image bumps across the range (`supabase/postgres` 17.6.1.087 → later patches, `postgres-meta`, `vector` 0.28.1 → 0.53.0, Studio image), plus `fix(analytics): wait for logflare before starting vector` (2.84.3) and `fix: use correct docker.sock binding with vector` (2.84.7). Full comparison: https://github.com/supabase/cli/compare/v2.76.14...v2.114.0 --- _Generated by [Claude Code](https://claude.ai/code/session_0143DrDMGnSSwuHebTPJv7ZY)_ --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
Supabase Studio E2E Tests
Set up
Prerequisites
For Self-Hosted Tests
- Nothing is required, running with IS_PLATFORM=false should run the tests locally with a self hosted docker container
For Platform Tests
- Create a platform account - You can authenticate using either:
- Email and password
- GitHub OAuth (requires TOTP 2FA)
- Create an organization on the platform, this can be done if run locally through
mise fullstack - Generate a Personal Access Token (PAT) for API access
- Configure the environment variables below (see Authentication section for details on email vs GitHub auth)
Configure Environment
Choose the appropriate example file based on your testing scenario:
For self-hosted tests:
cp .env.local.self-hosted.example .env.local
For platform tests with email authentication:
cp .env.local.email.example .env.local
For platform tests with GitHub authentication:
cp .env.local.github.example .env.local
Edit .env.local and set the appropriate values based on your test environment (see Environment Variables section below).
Install the playwright browser
⚠️ This should be done in the e2e/studio directory
cd e2e/studio
pnpm exec playwright install
Environment Variables
Configure your tests by setting the following environment variables in .env.local. We have examples of what required on self hosted and platform:
Core Configuration
STUDIO_URL: The URL where Studio is running (default:http://localhost:8082)API_URL: The Supabase API endpoint (default:https://localhost:8080)IS_PLATFORM: Set totruefor platform tests,falsefor self-hosted (default:false)- When
true: Tests run serially (1 worker) due to API rate limits - When
false: Tests run in parallel (5 workers)
- When
Authentication (Required for Platform Tests)
⚠️ Before running platform tests, you must create an account and organization on the platform you're testing.
Authentication is automatically enabled when either email/password OR GitHub credentials are configured.
Email Authentication
EMAIL: Your platform account emailPASSWORD: Your platform account passwordPROJECT_REF: Project reference (optional, will be auto-created if not provided)
When both EMAIL and PASSWORD are set, the tests will authenticate using email/password. HCaptcha is mocked during test setup. Note this only works on local and staging environments
GitHub Authentication
GITHUB_USER: Your GitHub usernameGITHUB_PASS: Your GitHub passwordGITHUB_TOTP: Your GitHub TOTP secret for 2FA (required, as GitHub enforces 2FA)
When GITHUB_USER, GITHUB_PASS, and GITHUB_TOTP are all set, the tests will authenticate using GitHub OAuth with TOTP-based 2FA. The authentication flow handles:
- Clicking "Sign In with GitHub" button
- Filling GitHub credentials
- Generating and submitting TOTP codes
- Handling GitHub authorization prompts
- Automatic retry on failure (up to 3 attempts)
Getting your GitHub TOTP secret:
When setting up 2FA on GitHub, you'll see a QR code. Click "enter this text code instead" to reveal the secret key. This is the value to use for GITHUB_TOTP.
Platform-Specific Variables (Required when IS_PLATFORM=true)
ORG_SLUG: Organization slug (default:default)SUPA_REGION: Supabase region (default:us-east-1)SUPA_PAT: Personal Access Token for API authentication (default:test)BRANCH_NAME: Name for the test branch/project (default:e2e-test-local)
Optional Variables
OPENAI_API_KEY: Required for the AI Assistant test (assistant.spec.ts). Without this variable, the assistant test will be skipped.VERCEL_AUTOMATION_BYPASS_SELFHOSTED_STUDIO: Bypass token for Vercel protection (default:false)
Setup Commands Based on Configuration
The test setup automatically runs different commands based on your environment:
- Platform + Localhost (
IS_PLATFORM=trueandSTUDIO_URL=localhost): Runspnpm run e2e:setup:platform - Platform + Remote (
IS_PLATFORM=trueand remoteSTUDIO_URL): No web server setup - Self-hosted (
IS_PLATFORM=false): Runspnpm run e2e:setup:selfhosted
Running the tests
Check the package.json for the available commands and environments.
pnpm run e2e
With Playwright UI:
pnpm run e2e -- --ui
Tips for development
- Read Playwright Best Practices
- Use
pnpm run e2e -- --uito get the playwright UI. - Add the tests in
examples/examples.tsto Cursor as context. - Add messages to expect statements to make them easier to debug.
Example:
await expect(page.getByRole('heading', { name: 'Logs', exact: true }), {
message: 'Logs heading should be visible',
}).toBeVisible()
- Use the test utility instead of playwrights test.
import { test } from '../utils/test'
- Use the PWDEBUG environment variable to debug the tests.
PWDEBUG=1 pnpm run e2e -- --ui
What should I test?
- Can the feature be navigated to?
- Does the feature load correctly?
- Can you do the actions (filtering, sorting, opening dialogs, etc)?
API Mocks
Read here: https://playwright.dev/docs/mock#mock-api-requests
Example:
await page.route(`*/**/logs.all*`, async (route) => {
await route.fulfill({ body: JSON.stringify(mockAPILogs) })
})