dima/supabase
1
0 Fork 0
mirror of https://github.com/supabase/supabase.git synced 2026-10-06 09:55:06 +03:00
Code Issues Packages Projects Releases Wiki Activity
38,871 Commits 1,781 Branches 62 Tags
codex/fix-tanstack-e2e
Commit Graph
22 Commits
Author SHA1 Message Date
Manan GuptaandJoshen Lim 6a0518dd86 fix(studio): forward HA flag to project-creation pre-flight checks (#50902) 
## Summary

- Fixes MUL-1678: toggling High Availability on in the project-creation
wizard 400'd for orgs that are HA-entitled but not enrolled in the "V3
rollout ramp" feature flag on the backend, because two pre-flight
endpoints Studio calls before project creation didn't know about HA and
hit the ramp check the real create-project call already bypasses.
- Threads `highAvailability` through
`useOrganizationAvailableRegionsQuery` (`GET
/platform/projects/available-regions`, sent as
`high_availability=true|false` on the query string) and
`useProjectCreationPostgresVersionsQuery` /
`useAvailableOrioleImageVersion` (`POST
/platform/organizations/:slug/available-versions`, sent as
`high_availability` in the body), including their query-key cache keys
so HA and non-HA responses for the same org/provider/size don't collide.
- Wires the (already form-tracked) `highAvailability` value into every
call site: `ProjectCreationForm.tsx`, `RegionSelector.tsx`, and a new
`highAvailability` prop on `PostgresVersionSelector.tsx` passed from
`InternalOnlyConfiguration.tsx`.

## Problem

The project-creation wizard's HA toggle is wired into the actual
project-create request, but two pre-flight calls Studio makes before
that (available regions, available Postgres versions) had no way to
signal HA, so the backend's ramp-flag gate rejected them for HA-entitled
orgs outside the ramp.

## Solution

Add an optional `highAvailability` field end-to-end on the Studio side:
query hook variables, cache keys, request serialization, and the
components that already track the toggle via `useWatch`.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Bug Fixes**
* Available regions and database versions in project creation now
reflect the selected high-availability setting.
* The Create button remains disabled while available regions are
loading.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Signed-off-by: GuptaManan100 <guptamanan100@gmail.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
 2026-09-29 20:39:01 +05:30
Joshen Lim 93a262d185 Check region selection for project creation (#51012) 
## Context

Previously added telemetry for `selectedRegionOption` and
`selectedRegionOptionType`
[here](https://github.com/supabase/supabase/issues/50851) if the best
available region option is available for users

Opting to extend this telemetry (still just for Free plan orgs)
irregardless if best available region was selected and include
`initialRecommendedRegion`

Main thing to understand is what regions users are spinning projects up
in outside of the recommended option

## To test
- [ ] Verify the telemetry network request after creating projects
- [ ] Non-free plan: Telemetry request doesn't have
`initialRecommendedRegion` in the payload
- [ ] Free plan: Telemetry request has `initialRecommendedRegion` in the
payload
- Sends correctly if best available region option is available (default
behaviour for staging)
- Sends correctly if best available region option is NOT available
(override with dev tools the configcat flag)
 2026-09-29 16:34:03 +08:00
Jordi Enric 8f6a6f7032 fix(studio): wait for organization before loading regions (#50572) 
## Problem

The new-project page can request available regions with a paid compute
size before the selected organization plan resolves. For free
organizations, this produces a failed request followed by a successful
request without the size.

## Fix

Delay both available-regions query observers until the selected
organization resolves, while preserving size-dependent refetches. Add
request-level coverage for the initial free- and paid-plan behavior.

## How to test

- Run `pnpm --filter studio exec vitest --run
'tests/pages/new/[slug].test.tsx'`.
- Open the new-project page for a free organization and inspect the
available-regions request.
- Expected result: one initial request is sent without
`desired_instance_size`; paid organizations send one initial request
with `desired_instance_size=micro`.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

- **Bug Fixes**
- Improved project creation so available regions are loaded only after
an organization is selected.
- Ensured region availability requests use the appropriate instance size
for the organization’s plan: no size parameter for free plans and
`micro` for paid plans.
- Prevented unnecessary region-availability requests when no
organization has been selected.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-09-29 10:25:32 +02:00
Joshen Lim 0d3b73794b Joshenlim/fe 4465 experiment with best available region selection (#50851) 
## Context

Adds a "Best available region" option in the region selector for the
project creation form
- Should only show up for free plan organizations (will be selected as
the default option instead of the recommended option from GET
`/available-regions`)
- "Recommended" badges will also be hidden in this scenario
- Behaviour should be status quo for non free plan organizations
<img width="500" alt="image"
src="https://github.com/user-attachments/assets/de0a183d-37c0-445d-98ca-c5aaf6353e73"
/>

## To test
Important to ensure that project creation still behaves as per usual
- [ ] Free plan: Creating a project with "best available region" select
creates the project if the recommended region from GET
`/available-regions`
- A quick way to check this is to swap to a paid org and see the
"recommended" general region
- [ ] Free plan: Can also create a project with other regions selected
as per usual
- [ ] Non free plan: Can create project as per usual
- [ ] Verify that everything is status quo if configcat feature flag is
off
 2026-09-24 17:38:58 +08:00
kemal.earth 24e8333c54 feat(studio): flag for unavailable regions (#50473) 
## 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?

Adds feature flag for controlling region unavailability.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Region options now display availability badges, tooltips, and
status-specific notices.
* Restricted regions remain selectable so users can review their
availability status.
* Project creation provides a clear field-level message when a selected
region is unavailable and prompts users to choose another region.

* **Bug Fixes**
* Region availability messaging now consistently reflects platform
status and configured restrictions.
  * Availability warnings clear after selecting an eligible region.
  * Region checks now cover both dynamic and static provider regions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-09-17 14:42:58 +01:00
Joaquim Moreno Prusi b824acdfd2 feat(project-creation): support Kubernetes cluster override for internal project creation (#49956) 
## 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?

Feature, internal

## What is the current behavior?

When creating a project, the worker will use load balancing to decide
where to deploy a cluster.

## What is the new behavior?

An internal user can choose a specific cluster and even bypass the
CORDONED state by forcing deployment.


## Additional context

This PR adds kubernetesClusterId and kubernetesClusterForce to the
internal-only project creation form for K8S cloud providers, gated by
schema validation (provider-restricted; force requires an ID) and
cleared automatically on provider change. The override is a one-time
creation-time steer, not a persistent pin, and the UI copy reflects
that. Includes the matching
kubernetes_cluster_id/kubernetes_cluster_force request fields in the
generated platform API types.

<img width="1620" height="1352" alt="image"
src="https://github.com/user-attachments/assets/bd8965a1-cec8-4428-aac1-46d0bf3b89d3"
/>


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Added Kubernetes cluster ID entry during project creation for
supported cloud providers.
  * Added an option to force deployment to a specified cluster.
* Clarified that eligible clusters must meet status and filesystem
requirements.

* **Bug Fixes**
* Prevented invalid or outdated Kubernetes settings from being submitted
when the provider or cluster selection changes.
  * Treated blank or whitespace-only cluster IDs as unset.
* Prevented force-deployment requests without a cluster ID or for
unsupported providers.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-09-15 13:46:49 +02:00
Danny White 476d4a5851 refactor(ui): drop redundant Button variant="default" props (#50161) 
## What kind of change does this PR introduce?

Mechanical cleanup on top of the Button default-variant change (#50160).

## What is the current behavior?

Many callsites still pass `variant="default"` even though that is now
the component default.

## What is the new behavior?

Removes redundant static `variant="default"` from legacy `Button` and
`ButtonTooltip` callsites. Keeps explicit defaults where they document
the API:

- `button-default.tsx` and `button-sizes.tsx` demos
- `DocsButton`, which pins neutral styling at the wrapper boundary

## To test

Studio:

- [Auth → Rate
Limits](https://studio-staging-2s957kwc4-supabase.vercel.app/dashboard/project/_/auth/rate-limits):
dirty the form so Cancel appears; Cancel stays neutral, Save stays green
- [Project Settings → API
Keys](https://studio-staging-2s957kwc4-supabase.vercel.app/dashboard/project/_/settings/api-keys):
`DocsButton` in the header actions stays neutral

Design system:

- [Design system →
Button](https://design-system-git-dnywh-dc924ac1-supabase.vercel.app/design-system/docs/components/button):
`button-default` / `button-sizes` still show explicit default styling;
Primary (green) is restricted to the Primary section (and `asChild`)

WWW:

- [www → Brand
assets](https://zone-www-dot-com-git-dnywh-dc924ac1-supabase.vercel.app/brand-assets):
Download logo kit / Download button kit stay neutral
 2026-09-11 17:05:26 +10:00
Alaister YoungandAlaister Young caceeb429f [MUL-1336] fix(studio): show HA project costs as free during Alpha (#49383) 
HA (Multigres) projects are free during Alpha, but the project creation
form still presented the forced large compute as a real charge. The
footer now shows **$0/m** for HA projects, with the usual compute price
struck through + a "Free during Alpha" note in the cost-breakdown
tooltip and the compute size dropdown. Follows the pattern from #49249.

Addresses
[MUL-1336](https://linear.app/supabase/issue/MUL-1336/bug-when-creating-new-projects).

<img width="688" height="167" alt="Screenshot 2026-08-21 at 5 27 39 PM"
src="https://github.com/user-attachments/assets/804b9243-77ae-4961-9083-5e1290734d3a"
/>
<img width="503" height="202" alt="Screenshot 2026-08-21 at 5 27 32 PM"
src="https://github.com/user-attachments/assets/f217edd4-2204-4e5e-87f8-f54974e3c6fa"
/>

**Changed:**
- `ProjectCreationFooter`: "Additional costs" shows `$0/m` when HA is
on; the tooltip gains a "High availability projects are free during
Alpha for up to 2 projects." sentence; the New-project row's price
renders struck through with a "Free during Alpha" sub-line; the HA
project's compute is excluded from "Total Monthly Compute Costs"
(clamped at 0 so credits can't produce a negative total — a no-op for
non-HA since spend already floors above zero)
- `ComputeSizeSelector`: the per-option `$X/hour (~$Y/month)` line
renders struck through with "Free during Alpha" beneath it when HA is on
(both tagged `data-field="instance-details"` so the collapsed trigger
keeps hiding them)
- `ProjectCreationForm`: threads the watched `highAvailability` value
into the footer

The "Confirm compute costs" modal was already suppressed for HA by the
existing `!values.highAvailability` guard — no change needed there.

## To test

- On a paid org, open New Project and toggle High Availability on: the
footer should read `$0/m` (brand green, no strikethrough), its ⓘ tooltip
should show the HA sentence and the New row's `$110` struck through with
"Free during Alpha", and the Total should exclude the $110; the compute
dropdown's Large option should show its price struck through with "Free
during Alpha"
- Toggle HA off (and on/off a few times): all cost displays should
revert exactly to normal — green real price, no strikethrough, no "Free
during Alpha" anywhere outside the HA toggle's own description
- With HA off and compute size Medium, submit: the "Confirm compute
costs" modal should still appear as before (Cancel works)
- Collapsed compute-size trigger should never show a price line or "Free
during Alpha" in either state

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

## New Features

- High-availability project options now show compute pricing as free
during Alpha.
- Standard compute prices are displayed with a strikethrough alongside
the Alpha-free notice.
- Project cost summaries accurately show no additional compute charge
for high-availability selections.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
 2026-08-24 16:10:14 +08:00
Alaister YoungandAlaister Young aa3643f39d fix(studio): restrict geolocated default region to provider regions (#49141) 
Follow-up to #49131. For `AWS_NIMBUS` orgs, the new-project form's
Region trigger could show a region that wasn't in the dropdown at all
(e.g. "Southeast Asia (Singapore)" while the list only offered "East US
(North Virginia)"). The geolocation-based default region
(`useDefaultRegionQuery`) picked the nearest region from **all** AWS
regions and seeded it into `dbRegion` unvalidated, ignoring the
provider's restricted region list.

**Changed:**

- `getDefaultRegionOption` now computes the nearest region only over the
provider's available regions (new `getDefaultRegionCandidateKeys`
helper). The flag-based restricted pool (`defaultRegionRestrictedPool`)
narrows within that set and is ignored if the intersection would be
empty.
- The form's default-region selection is extracted into
`resolveDefaultDbRegion` (`ProjectCreation.utils.ts`): High Availability
region first, then the recommended smart region, then the geolocated
default — used only when the provider actually offers that region —
falling back to the provider's static default.
- `getAvailableRegions` takes an injectable `environment` param (same
pattern as `getHighAvailabilityRegionCode`) so the prod-only Nimbus
region list is unit-testable.

**Added:**

- Unit tests for `getDefaultRegionCandidateKeys` (provider clamping
incl. Nimbus on prod, restricted-pool intersection, empty-intersection
fallback), `getAvailableRegions` across environments, and
`resolveDefaultDbRegion` (branch priority plus the fallback when the
geolocated region isn't offered).

## To test

- Emulate a Nimbus org locally by setting `"infra:cloud_providers":
["AWS_NIMBUS"]` in
`apps/studio/hooks/custom-content/custom-content.json`, then open the
new-project form: the Region trigger must show the same region the
dropdown offers (locally that's only Southeast Asia (Singapore)). To
reproduce the original mismatch path, stub
`https://www.cloudflare.com/cdn-cgi/trace` to return `loc=US` — the
trigger should still be clamped to the provider's region rather than
showing a US region
- Block or fail the Cloudflare trace request: the trigger should fall
back to the provider's static default region, not sit blank or loading
- Restore the normal provider list: the smart-region flow ("General
regions" + "Specific regions" with Recommended badges) is unaffected —
the geolocation request doesn't even fire on that path — and toggling
High Availability still transitions the region list cleanly

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

## Summary by CodeRabbit

- **Bug Fixes**
- Region suggestions now respect the selected cloud provider and
deployment environment.
- Project creation avoids unavailable geolocated regions and falls back
to a supported provider default.
- Restricted region pools now fall back reliably to available provider
regions.
- AWS Nimbus selection reflects the active environment while preserving
high-availability and smart-region behavior.

- **Tests**
- Added coverage for provider-specific, environment-specific,
restricted, and fallback region selection scenarios.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
 2026-08-21 15:51:03 +08:00
Alaister YoungandAlaister Young de4bec77d6 [MUL-1338] fix(studio): lock compute size to large for HA projects (#49249) 
When the High availability (Multigres) toggle is enabled in the New
Project form, the Compute size dropdown now offers only **Large** and
the form value is forced to `large`. Previously HA projects showed the
same micro/small/medium options as regular projects.

**Added:**
- `HIGH_AVAILABILITY_INSTANCE_SIZE` constant (`'large'`) alongside the
other `HIGH_AVAILABILITY_*` constants

**Changed:**
- `ComputeSizeSelector` watches `highAvailability` and renders only
Large when it's on (hiding the "Larger instance sizes available after
creation" row); the `cloudProvider` read is now a reactive `useWatch`
instead of a render-time `getValues()`, so the list re-filters when HA
forces the provider to `AWS_K8S`
- `HighAvailabilityInput` forces `instanceSize` to `large` when HA
toggles on and restores the previously selected size when it toggles
off, alongside the existing `dbRegion`/`cloudProvider` handling
- The compute size and region selects ignore Radix's spurious
`onValueChange('')` — Radix emits it when a select's value and option
list change in the same tick, which wiped the forced value (details in
the inline comments)
- HA projects skip the "Confirm compute costs" modal on submit — HA is
free during Alpha, so the forced large size shouldn't trigger the
$110/mo confirmation

## To test

- On a paid org, open the New Project form: with HA off, the Compute
size dropdown shows micro/small/medium plus the disabled "Larger
instance sizes available after creation" row
- Toggle High availability on: the dropdown shows only Large, the
trigger reads "large / 8 GB RAM / 2-core CPU" (not the placeholder), the
region locks as before, and the footer shows $110/m
- Check the network tab: the `available-regions` request goes out with
`desired_instance_size=large` and returns 200 (no request with an empty
`desired_instance_size`)
- Select medium first, toggle HA on then off: medium is restored (same
for other sizes); rapid toggling shouldn't leave the field blank
- With HA on, submitting goes straight through without the "Confirm
compute costs" modal; a non-HA medium project still shows it

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **New Features**
* High-availability projects now automatically use the required
dedicated instance size.
* Disabling high availability restores the previously selected instance
size.
* Compute size options are filtered based on cloud provider and
high-availability settings.

* **Bug Fixes**
* Prevented accidental clearing of compute size or region selections
during option updates.
* Compute-cost confirmation is no longer required for high-availability
projects.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
 2026-08-19 13:03:39 +00:00
Danny White c15a8b6739 chore(studio): lighten FormLayout descriptions and tighten GitHub copy (#49091) 
## What kind of change does this PR introduce?

UI nits

## What is the current behavior?

`FormLayout` descriptions that are not in a react-hook-form field use
`text-foreground-light`, which fights the component’s
`text-foreground-lighter` variant. New-project GitHub helper copy is one
long colon sentence.

## What is the new behavior?

Those `FormLayout` descriptions use the shared description variant
(`foreground-lighter`). New-project GitHub copy is two short sentences.

| Figure |
| --- |
| <img width="820" height="798" alt="CleanShot 2026-08-14 at 14 33
32@2x"
src="https://github.com/user-attachments/assets/7703a01d-efcb-41c2-8f6a-e96fc8a7187d"
/> |
| _Example call site of **before** the `FormLayout` fix._ |
| <img width="1384" height="582" alt="CleanShot 2026-08-14 at 14 53
39@2x"
src="https://github.com/user-attachments/assets/1bce1ee7-befd-4f53-881c-bbc7a87dd467"
/> |
| _**After** New-project copy shortening._ |

## To test

- **Organization → New project.** GitHub (optional): “Ideal for
agent-first workflows. Update your schema in code and push it to GitHub.
Supabase deploys the changes.”
- **Project Settings → Database → SSL configuration.** “Reject non-SSL
connections to your database” should look more muted
(`foreground-lighter`), not the brighter `foreground-light`.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
* Simplified the GitHub repository field description while preserving
deployment guidance and the “Learn more” link.

* **Style**
* Lightened the color of descriptive text in form layouts for improved
visual hierarchy.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-08-17 11:29:59 +10:00
Joshen Lim bddb806b57 Joshenlim/fe 4174 project creation ignores selected us east 1 region (#49092) 
## Context

Addresses a bug on local only whereby when toggling HA in the project
creation form, the database region was getting fixed to eu-central-1
irregardless of the region that was chosen on the UI. Was a result of
old code that wasn't cleaned up when we introduced region selection for
HA locally.

Added regression test to cover this case as well 🙏 

## To test
Can only be tested locally
- [ ] On the project creation form, toggle HA and create a project in
us-east-1 - the project should be created in the selected region, and
not eu-central-1

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

- **Bug Fixes**
- Fixed project creation so high-availability settings no longer replace
a manually selected database region.
- Smart-region providers continue using the selected smart or specific
region.

- **Tests**
- Added regression coverage to verify that manually selected regions are
submitted correctly in local high-availability environments.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-08-14 20:38:00 +07:00
Danny WhiteandJoshen Lim 6b1fc3d11d recover failed Vercel deploy connections (#48474) 
## What kind of change does this PR introduce?

Bug fix.

## What is the current behavior?

A failed Vercel connection after project creation is only logged,
leaving the project-creation screen in its loading state.

## What is the new behavior?

The flow preserves the created project and shows the connection error
with retry and open-project actions in the standard project-creation
footer.

Project-creation failures remain ordinary inline form errors. Connection
failures are owned by this flow without a duplicate toast or a no-op
error handler.

| Before | After |
| --- | --- |
| ![Create Vercel Project
Supabase](https://github.com/user-attachments/assets/18dfb6d1-614a-4298-bf28-8399d86c7bca)
| <img width="1024" height="563" alt="Create Vercel Project Supabase"
src="https://github.com/user-attachments/assets/b7d3fdca-d7a0-4b50-9231-3cf7dc371a87"
/> |

## To test

### Before on master

1. Switch to `master`.
2. With local Studio running and while signed in, open an organisation
you can access. Copy its slug from
`http://localhost:8082/org/<YOUR_ORG_SLUG>`.
3. Open
`apps/studio/components/interfaces/ProjectCreation/ProjectCreationForm.tsx`.
4. Find `isSuccessNewProject={isSuccessNewProject}` in the
`ProjectCreationFooter` props and temporarily change it to:
   ```tsx
   isSuccessNewProject={true}
   ```
5. Replace `<YOUR_ORG_SLUG>` in this URL with the slug from step 2, then
open it:
`http://localhost:8082/integrations/vercel/<YOUR_ORG_SLUG>/deploy-button/new-project`.
6. Confirm **Create new project** remains in its loading state and there
is no error, retry action, or route to the created project. This
represents the current stuck state.
7. Revert the temporary edit before switching branches.

### After on this branch

1. Switch to `dnywh/vercel-deploy-recovery`.
2. With local Studio running and while signed in, open an organisation
you can access. Copy its slug from
`http://localhost:8082/org/<YOUR_ORG_SLUG>`.
3. Open
`apps/studio/pages/integrations/vercel/[slug]/deploy-button/new-project.tsx`.
4. Find the conditional beginning with `newProjectRef === undefined`
inside `InterstitialLayout`.
5. Replace that whole conditional with:
   ```tsx
   <VercelConnectionError
     projectRef="abcdefghijklmnopqrst"
     message="Connection request failed"
     onRetry={() => undefined}
   />
   ```
6. Replace `<YOUR_ORG_SLUG>` in this URL with the slug from step 2, then
open it:
`http://localhost:8082/integrations/vercel/<YOUR_ORG_SLUG>/deploy-button/new-project`.
7. Confirm the admonition says **Unable to connect to Vercel** and
**Your Supabase project was still created. Error: Connection request
failed**.
8. Confirm **Open project** and **Retry connection** appear as compact,
right-aligned footer buttons. The retry action is intentionally inert in
this visual-only mock, and no project or Vercel connection is created.
9. Revert the temporary edit.

## Additional context

Follows #48473. The consistency follow-up #48640 is stacked on this PR.



<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **New Features**
- Added inline error messages to project creation forms for integration,
API, and validation failures.
- Added clear Vercel connection states, including waiting, connecting,
success, and error screens.
  - Added retry actions and links to open successfully created projects.

- **Bug Fixes**
- Improved error handling so Vercel connection issues remain visible in
context instead of appearing only as notifications.

- **Tests**
- Added coverage for partial-success messaging, project links, and retry
behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
 2026-08-06 10:49:50 +10:00
Saxon FletcherAlaister YoungJoshen Lim
 		d2a3162bf1 Add high availability project creation controls (#48375) 
## Summary

- Move High Availability into the standard project creation settings
above Compute, gated by the `instances.high_availability` entitlement.
- Mark the option as Alpha and explain that it is free during Alpha for
up to two projects.
- Enforce the supported HA configuration: `AWS_K8S`, Postgres 17 on the
`ga` release channel (no custom version is sent — the API resolves the
image), and the environment-specific local/staging region restrictions.
- Show eligible locations in a dedicated **High Availability Regions**
group.
- Preserve the existing Advanced Configuration availability rules and
additionally hide the section while HA is enabled.
- Restore the previous provider and Postgres settings when HA is
switched off.

## How to test
1. Go to create a new project
2. Ensure you have access to high availability (e.g. on local)
3. Toggle high availability on and note how the project form restricts
settings listed above

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Added High Availability to project creation with Alpha warning
labeling and improved switch accessibility.
* Constrains region selection to compatible High Availability regions
and enforces HA-specific engine/release settings.
* Disables/hides custom PostgreSQL version selection when High
Availability is enabled (and omits HA custom request payloads).

* **Bug Fixes**
* Improved persistence of selected PostgreSQL version and region across
data reloads and configuration panel reopen/toggle.
* Restores region when form state temporarily drops values during
remounts.

* **Tests**
* Expanded end-to-end coverage for HA UI, region grouping, and
submit/payload restoration behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
 2026-07-30 16:36:54 +08:00
Alaister YoungandAlaister Young ca2b50a0a7 chore(ui-patterns): collapse the admonition shim into ui-patterns/Admonition (#48377) 
Follow-up to #48344: collapses the two resolution paths for the
Admonition module into one.

`src/admonition.tsx` was a back-compat shim re-exporting
`src/Admonition/`. Two ways to resolve one module is exactly what
produced the macOS self-import bug fixed in #48344, and the local
typecheck errors that #48374 worked around. This removes the shim and
standardizes on the PascalCase subpath, matching every other export in
the package.

**Changed:**

- Codemodded all 246 `ui-patterns/admonition` imports to
`ui-patterns/Admonition` (240 `.tsx`, 5 `.mdx`, 1 `.ts` across studio,
docs, www, design-system, and lite-studio)
- Pointed the 5 internal `'../admonition'` imports back at the
`'../Admonition'` directory

**Removed:**

- `packages/ui-patterns/src/admonition.tsx`, and its `./admonition`
entry in the exports map (regenerated with `pnpm gen:exports`)

## To test

- `grep -r "ui-patterns/admonition" --include='*.ts*'` → no hits
- `pnpm test:case-hazards` → passes
- `pnpm typecheck` → all 15 tasks green
- `pnpm --filter studio run lint:ratchet` → passes
- `pnpm --filter ui-patterns vitest run src/Admonition` → 11 tests pass

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Standardized Admonition component imports across the application and
documentation.
* Improved compatibility with case-sensitive environments by using the
canonical component path.
  * Removed the legacy Admonition import entry point.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
 2026-07-29 00:48:56 +08:00
Danny WhiteandJoshen Lim 69f3c43118 fix(studio): close Vercel create popup on cancel (#48371) 
## What kind of change does this PR introduce?

Bug fix / UX polish.

## What is the current behavior?

Cancel on the Vercel create interstitial redirects to Vercel’s `next`
URL. That finishes the install flow and shows “Completing installation…”
/ “Installation complete”, even though the user cancelled. The Deploy
Button job still proceeds and fails. The button was also labelled
“Return to Vercel”, which read like an alternate success path.

| Before |
| --- |
| <img width="719" height="118" alt="Create Vercel Project Supabase"
src="https://github.com/user-attachments/assets/c7ad261a-f132-4226-b460-21ec267595c0"
/>|
| <img width="800" height="599" alt="95801"
src="https://github.com/user-attachments/assets/6d235c4b-be90-4d5e-89bc-a68933f9dc46"
/> |

## What is the new behavior?

- _Return to Vercel_ button now labelled **Cancel**
- **Cancel** closes the popup via `window.close()` (same honest abort as
manually closing the window)
- If the browser blocks programmatic close, Cancel is replaced by muted
fallback copy: “Close window to cancel” (`role="status"` /
`aria-live="polite"`)
- Cancel is left-aligned with `justify-between` when there’s no
additional-costs block; with costs, both actions stay on the right
- Removes the free-limit hint line about returning to Vercel (Cancel
makes that self-evident)
- Success path is unchanged: after create, we still redirect via `next`
- `/new` Cancel still navigates into Studio (`cancelAction: 'studio'`).
This is unchanged behaviour

| After (Fallback) |
| --- |
| <img width="713" height="103" alt="img"
src="https://github.com/user-attachments/assets/95aafc0d-1c3d-4093-9681-88ad0a40f9fe"
/> |

## Additional context

Follow-up to #48311. Vercel’s `next` URL has no documented cancel/abort
status, so closing the popup is the correct escape hatch.

### To test

Full Deploy Button popup cancel can’t be verified on prod until this
merges. Locally:

1. Open Studio on this branch.
2. In `ProjectCreationFooter.tsx`, temporarily force the fallback:
   ```ts
   const [showCloseWindowHint, setShowCloseWindowHint] = useState(true)
   ```
3. Load create-project UI:
- Free org / no costs: Confirm Cancel is left, Create is right
(`justify-between`). With the forced hint, Cancel is replaced by “Close
window to cancel”.
- Paid org with additional costs: Confirm costs on the left; hint/Create
on the right.
4. Revert `useState` to `false`.
5. Optional: open a Vercel create interstitial URL in a normal tab (not
a popup), click Cancel. `window.close()` fails and the hint should
replace Cancel after ~100ms.
6. On `/new/[slug]`, Confirm Cancel still returns to the Studio
dashboard (not close-window).

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

## Summary by CodeRabbit

* **New Features**
* Updated Project Creation Cancel to close the popup window directly
when applicable, with a “close window to cancel” hint when closing isn’t
available.
* **Bug Fixes**
* Removed Vercel-specific “return and restart” messaging and related
return-url handling.
* Standardized Cancel navigation for non-popup flows to return to the
last relevant location (or the organizations page).
* **Refactor**
* Improved Project Creation footer layout/visibility for additional cost
details.
* **Chores**
* Simplified the free-project limit warning configuration by removing an
unused option.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
 2026-07-28 15:28:00 +10:00
Danny WhiteandJoshen Lim c9ed51c99e fix(studio): add return to Vercel escape hatch (#48311) 
## 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?

Bug fix / UX improvement for the Vercel Deploy Button create-project
interstitial.

## What is the current behavior?

On the Vercel create-project step, the organization picker is locked
(correct — the integration is bound to that org) and Cancel is hidden.
If the org can't create a free project (member free-project limits),
users hit a dead end: Upgrade may not help, and there's no way out of
the popup.

Also includes a small capitalisation nit on the Vercel install page.

| Before |
| --- |
| <img width="800" height="629" alt="Create Vercel Project Supabase"
src="https://github.com/user-attachments/assets/2acdc7a3-eb99-43c6-9135-557370647da1"
/> |

## What is the new behavior?

- Replaces `hideCancelButton` with `cancelAction: 'studio' | 'vercel' |
'hidden'`
- Vercel create flow shows **Return to Vercel**, which redirects to the
install `next` URL (closing the popup cleanly)
- Free-project-limit admonition adds a Vercel-only hint pointing at that
button: “Or return to Vercel and restart with a different organization.”
- Main `/new` Cancel behaviour is unchanged
- Org picker stays disabled

## Additional context

Org switching mid-create is intentionally not allowed. That would orphan
the Vercel install. Returning to Vercel is the safe escape hatch so
users can restart Deploy Button with another org, or free a project slot
/ upgrade and try again.

## To test

As far as I can tell, this is impossible to test on prod. Shortly after
merge though, you could test the following:
- [ ] Happy path: create still works; Return to Vercel is secondary and
does not block submit
- [ ] Free-limit blocked org: Create disabled, Return to Vercel visible
and redirects to `next`
- [ ] Main `/new`: Cancel still goes to last org / organizations

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **New Features**
- Enhanced project creation flow for Vercel: when a valid return
destination is available, users can choose **“Return to Vercel”**.
- Added additional messaging in the free-project-limit warning to guide
users back to Vercel and restart with a different organization (when
applicable).
- **Bug Fixes**
- Improved cancel behavior and routing consistency by only enabling
Vercel return when the destination is valid.
- **Style**
- Updated the Vercel integration interstitial title capitalization for
consistency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
 2026-07-28 08:14:01 +10:00
Bobbie Soedirgo 60e6a89f9d fix: make high availability in project creation form public (#48338) 
Move "High availability" from internal-only to public. Closes MUL-668.

## 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?

Bug fix

## What is the current behavior?

"High availability" is an internal-only config

<img width="724" height="1126" alt="Screenshot 2026-07-26 at 8 15 57 PM"
src="https://github.com/user-attachments/assets/83e1856b-9020-4b65-a019-27e3cc29bae9"
/>

## What is the new behavior?

"High availability" is a public user-facing config

<img width="724" height="1036" alt="Screenshot 2026-07-26 at 8 15 31 PM"
src="https://github.com/user-attachments/assets/4f369058-ce91-4bcf-bd3c-120277363b1a"
/>

Still hidden without the org entitlement, i.e. currently not available
anywhere on prod

<img width="724" height="931" alt="Screenshot 2026-07-26 at 8 18 58 PM"
src="https://github.com/user-attachments/assets/3e1deb76-210c-416b-b716-45ff6e3b0afd"
/>



<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **New Features**
* Added a High availability option directly to the project creation
form.
* The option is shown when available for the account and hidden when
unavailable.
* Enabling High availability automatically selects AWS as the cloud
provider.

* **Bug Fixes**
* Corrected validation for incompatible High availability and OrioleDB
selections.

* **Tests**
* Added coverage for High availability visibility, eligibility, and form
submission behavior.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-07-27 18:11:35 +08:00
Danny White b6ed55e272 fix(studio): restore project creation panel chrome on /new (#48171) 
## What kind of change does this PR introduce?

Bug fix

## What is the current behavior?

Regression from #48113: the regular `/new` project creation form is
missing its card border/shadow because Panel flatten classes were
applied when `!isVercelIntegrationFlow`.

## What is the new behavior?

Flattens Panel chrome only for the Vercel interstitial flow, restoring
the card on `/new`.

| Before | After |
| --- | --- |
| <img width="980" height="997" alt="New Project Supabase"
src="https://github.com/user-attachments/assets/5af9bc8b-5abd-47ea-9821-207ea5c2c127"
/> | <img width="980" height="997" alt="New Project Supabase"
src="https://github.com/user-attachments/assets/28a32216-d250-497c-90df-94e2df19ce00"
/> |

## Additional context

N/A

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Updated the project creation panel’s appearance during the Vercel
integration flow, removing unnecessary borders, shadows, and background
styling.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-07-21 17:42:26 -04:00
Danny WhiteandJoshen Lim 0324f3422a chore(studio): polish vercel deploy-button new project interstitial (#48113) 
## 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?

Studio UI polish for the Vercel deploy-button new-project connect flow
(DEPR-616 follow-up).

## What is the current behavior?

- Deploy-button project creation still used
`VercelIntegrationWindowLayout` (top bar + Docs/Support footer) while
install and choose-project already use shared `InterstitialLayout`
- The remove-integration note sat as a floating admonition above the
form
- Advanced / internal-only config sections could show double dividers,
and the Oriole radio bottom border could clip inside the collapsible

## What is the new behavior?

- Deploy-button new-project uses `InterstitialLayout` with
`VercelIntegrationLogo` and `VercelIntegrationFooter`, matching the
other Vercel connect surfaces
- Regular `/new` project creation is unchanged; Panel chrome is only
flattened when `isVercelIntegrationFlow` is set
- Removes unused `VercelIntegrationWindowLayout` /
`IntegrationWindowLayout`
- Fixes Advanced/Internal-only dividers and collapsible border clipping

| Before | After |
| --- | --- |
| <img width="965" height="1107" alt="Supabase"
src="https://github.com/user-attachments/assets/99c1225c-c9e5-4fac-bd64-17920403e447"
/> | <img width="965" height="1107" alt="Create Vercel Project Supabase"
src="https://github.com/user-attachments/assets/c42bff96-5f9f-4c8b-8f3c-093e380f90ed"
/> |

## Additional context

### Testing

With Studio running locally and while signed in:

1. Open
`http://localhost:8082/integrations/vercel/<your-org-slug>/deploy-button/new-project`
2. Confirm the interstitial card: Vercel + Supabase logo pair, “Create a
new project” title, form fields, and the muted remove-integration footer
under the card
3. Confirm there is no old window chrome (no “Marketplace Connector” /
“Deploy Button” top bar, no Docs/Support footer)
4. Optionally submit and confirm project creation still works
5. Spot-check `/new` to confirm the normal project creation form is
unchanged

If you have advanced config enabled, expand Advanced Configuration and
confirm single dividers (not doubles) and that the Oriole option’s
bottom border is not clipped.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

## Summary by CodeRabbit

* **New Features**
* Added configurable width to the shared interstitial layout for Vercel
project creation.
  * Updated the Vercel “new project” flow to use the interstitial UI.

* **Bug Fixes**
* Prevented child borders/shadows from being clipped in expandable
configuration sections.

* **Refactor**
* Removed legacy Vercel/window layout components and updated routing to
rely on the interstitial flow.
* Switched advanced and internal-only configuration sections to render
inside panel content.

* **Documentation**
* Refreshed Vercel integration route guidance in the migration checklist
and inline route comments.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
 2026-07-22 00:08:00 +10:00
Joshen Lim 6e0078182b Consolidate project creation UI for vercel integration flow (#47995) 
## Context

There's 2 areas of the dashboard that has the project creation flow -
and this PR consolidates both to use the same UI components to minimise
duplication + keep things consistent

### Before
<img width="1920" height="957" alt="image"
src="https://github.com/user-attachments/assets/2a7ab79d-71c7-43f2-925b-1e1666cc3a69"
/>

### After
<img width="1389" height="957" alt="image"
src="https://github.com/user-attachments/assets/f8465568-af99-46eb-80ee-7ac345383231"
/>

## Changes involved
- What this means for the project creation flow for Vercel Integration:
  - Smart region can be selected
  - Compute size can be selected
  - Enable Data API can be checked
  - Automatic RLS enable can be checked
- How it differs from the main project creation flow on `new/slug`
  - Organization selection is disabled (cannot be changed)
  - The following UI is hidden:
    - "Internal configuration" section
    - "GitHub repository" field
    - "Free project info" at the bottom
    - "Cancel" button

Eventually we could looking into reducing the differences more, e.g
having data seeding for both ways, and showing GitHub repository field
for Vercel integration

Resolves DEPR-616
Resolves FE-3905

## To test
Tbh, I'm not really sure how you'd be able to test the vercel
integration locally or on staging, this seemingly can only be done when
changes land on prod.

- What I'd do however is to just test the project creation flow
minimally by landing on
`/integrations/vercel/_/deploy-button/new-project`
  - Project creation can work, but just not the connection creation part

- And also test project creation on `/new/slug` as well

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

## Summary by CodeRabbit

* **New Features**
  * Added “Create sample tables with seed data” during project creation.
* Enhanced Vercel integration setup with a guided creation flow and
post-creation connection step.
* Added an option to disable organization selection in specialized
flows.
* Added support for triggering a callback after successful project
creation.
  * Added support for hiding the Cancel button in specialized flows.

* **UI Improvements**
* Refined the connected GitHub repository selector button/dropdown
visuals.
* Improved security options behavior for different project creation
contexts.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-07-17 15:19:38 +08:00
Joshen Lim 22b3419a28 Extract project creation form into its own component (#47957) 
## Context

This is just a pre-requisite to consolidating the project creation UI as
there's another page that has the project creation flow too
[here](https://github.com/supabase/supabase/blob/master/apps/studio/pages/integrations/vercel/%5Bslug%5D/deploy-button/new-project.tsx).
So the next step will just be to use the same `ProjectCreationForm`
there

No functional changes here - just moving things around

## To test
- [ ] Verify that project creation still works



<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Added a full “create project” experience with eligibility-aware
defaults, advanced configuration sections, optional GitHub integration,
and compute-cost confirmation when applicable.
* **Improvements**
  * Enhanced project-creation success/error handling and navigation.
* Refined CLI backup/restore dialogs (better layout/wording,
accessibility updates, and improved section separation).
* **Documentation**
* Standardized all relevant documentation links across the app using a
shared `DOCS_URL` source.
* **Refactor**
* Refactored the “New Project” page to delegate the wizard UI and flow
to a reusable creation component.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-07-16 14:00:55 +08:00