No way to tell local Studios apart when several projects run at once

Start with apps/studio/lib/constants/api.ts and apps/studio/lib/api/self-hosted/settings.ts, then trace the env builders in apps/cli/src/legacy/commands/start/services/studio.service.ts and packages/stack/src/services/studio.ts. Determine which builder is active for the local stack and thread the existing project identifier into the Studio environment. Done means separate local Studios display distinct names, including in browser tabs, while preserving current defaults.

Affected area

Local development

Problem to solve

Running several projects locally at once is a supported workflow – each gets its own project_id and its own ports, and they run side by side without trouble. The trouble starts once they're up: every Studio is called "Supabase Studio (CLI)", and nothing else on the page tells them apart. The URL is 127.0.0.1:<port>/project/default in all of them, the ref is default in all of them, and the project_id sitting in config.toml never appears in the UI.

That name is the browser tab title too, so several open Studios render as identical tabs, truncated to the same few characters. The only thing separating them is the port in the address bar, so you end up keeping a mental port-to-project map and checking the URL before running anything.

Small on its own, but it comes up daily, and getting it wrong means querying the wrong local database.

Proposed solution

Let the local Studio show the project's own name, defaulting to the project_id already in config.toml.

Studio side – let an explicit name win. DEFAULT_PROJECT_NAME is still read in apps/studio/lib/constants/api.ts, but sits on the branch a CLI-started Studio can never reach:

name: !!process.env.CURRENT_CLI_VERSION
  ? 'Supabase Studio (CLI)'
  : process.env.DEFAULT_PROJECT_NAME || 'Default Project',

Reordering keeps today's default exactly, and only changes anything for someone who has set a name:

name: process.env.DEFAULT_PROJECT_NAME
  || (!!process.env.CURRENT_CLI_VERSION ? 'Supabase Studio (CLI)' : 'Default Project'),

That's also the shape apps/studio/lib/api/self-hosted/settings.ts already uses – process.env.DEFAULT_PROJECT_NAME || 'Default Project', no CLI branch – so a local Studio currently reports two different names depending on which path you ask. The reorder brings api.ts into line with it rather than inventing new behaviour.

CLI side – give the container a name to pass. Neither studio env builder has a project name available today: LegacyBuildStudioEnvInput in apps/cli/src/legacy/.../studio.service.ts and DockerStudioOptions in packages/stack/src/services/studio.ts both carry service wiring and credentials, but no project identifier – the newer one keys off StackIdentity instead. So this is threading the config value through to whichever of those is the long-term path, then setting DEFAULT_PROJECT_NAME beside CURRENT_CLI_VERSION. It's one more entry in an env map either way, so nothing here depends on which container runtime starts the service.

An optional [studio] name key in config.toml would cover anyone wanting a display name different from their project_id, but defaulting to project_id alone would solve it.

Alternatives considered

Memorising the ports. The status quo. It works, but it puts the work on the reader every time and does nothing for the tab title.

Overriding the container by hand. Recreating the studio container with CURRENT_CLI_VERSION stripped and DEFAULT_PROJECT_NAME set does work – Studio picks the name up immediately – but the CLI recreates the container on the next supabase start, so it silently reverts. Worse than not doing it.

Naming browser tab groups. A per-tab habit rather than a fix, and a freshly opened Studio is unlabelled again.

Additional context

The variable still works. Running the same studio image on a spare port with CURRENT_CLI_VERSION removed and DEFAULT_PROJECT_NAME set, /api/platform/projects returned the custom name immediately (checked on Docker). The mechanism is intact, just unreachable from the CLI.

Where the current string came from. supabase/supabase#45864 (merged 2026-05-13) introduced the ternary, replacing 'Default Project' with 'Supabase Studio (CLI)' as "a bit more meaningful". That holds for a single local stack – this request is only that the logic flips once more than one stack is running, and the fix leaves the default untouched for everyone else.

Related. discussion #5759 asked about multiple local projects and renaming the defaults back in 2022; the multiple-projects half was answered (out of scope by design), and the renaming half led to DEFAULT_PROJECT_NAME landing for self-hosted (supabase/supabase#6417) – the CLI path just never passed it.

Versions. CLI 2.115.0 · studio 2026.08.17-sha-0c1da8f · macOS.