This PR disables the following features on Multigres projects
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Enhanced replication interface with improved visual states.
* **Bug Fixes**
* Added validation to prevent incompatible database configuration
combinations.
* **Changes**
* High Availability projects now display informational notices
indicating unavailable features: Realtime, Replication, and PITR
backups.
* **Removed**
* Removed redundant UI component from the application.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.com>
<img width="1289" height="863" alt="image"
src="https://github.com/user-attachments/assets/d661f107-b358-4894-8531-80441d60ab91"
/>
GitHub integration is now available on the free plan and so we'd like to
start promoting code-first workflows as much as possible. One way to do
that is to set the tone straight away by asking a user to connecting
their GitHub repository to a project as part of project creation.
This PR:
- decouples GitHub connection and repo selection into a separate
component we can make use of in integration settings and project
creation.
- Adds new GitHub fields to project creation form and sends them off to
project creation endpoint
- Pre-fills project name based on repo selection
To test locally:
- Ensure you have GitHub integration set up locally (using ngrok etc)
- Ensure you are on the connected platform branch
- Open create a new project page
- Connect GitHub as part of the creation form and select a repo
- Create the project and wait for status to be healthy
- Check project settings integrations page and ensure repo is connected
Note:
- this requires changes on the management api end to accept new GitHub
fields
- it might make sense to pull out GitHub connection/authorization from
GitHub repository selection but in the current state they are tied
together.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* GitHub repository selection now available during project creation with
integrated authorization flow
* GitHub connection status and compute availability indicators now
displayed on project dashboard
* Project name auto-populates from selected GitHub repository name when
available
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.com>
## Summary
- Adds a "Custom instance type" input on the new-project modal, rendered
directly below the existing custom Postgres version field and gated
behind the same non-prod check.
- Wires the value through
`custom_supabase_internal_requests.ami.instance_type`, merged with the
existing AMI search-tag payload so both can be set independently.
<img width="312" height="133" alt="Screenshot 2026-05-07 at 12 32 41 PM"
src="https://github.com/user-attachments/assets/d4190a0f-0a54-46e6-ac0b-967548a3903f"
/>
## Test plan
- [x] On a non-prod build, open the new-project modal and confirm the
"Custom instance type" field appears below "Custom Postgres version".
- [ ] Submit with only an instance type set and verify the request body
includes `custom_supabase_internal_requests.instance_type` and no `ami`
block.
- [x] Submit with both fields set and verify both `ami.search_tags` and
`instance_type` are sent.
- [x] Submit with neither set and verify
`custom_supabase_internal_requests` is omitted.
- [x] Verify the field is hidden in prod builds.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added instance type field to project-creation wizard.
* Added an internal-only configuration panel for advanced customization.
* **Refactor**
* Simplified Advanced Configuration panel layout and behavior.
* **Documentation**
* Updated documentation links to use internal reference URLs.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
<img width="783" height="414" alt="Screenshot 2026-04-20 at 3 02 37 PM"
src="https://github.com/user-attachments/assets/a353c35a-3de5-4bfa-ab31-829c79c43165"
/>
Adds a "Default privileges for new entities" checkbox under "Enable Data
API" in both the main create flow and the Vercel deploy-button flow.
Default checked (current behaviour). When unchecked, runs
`buildDefaultPrivilegesSql('revoke')` after the base init script so new
entities in `public` aren't auto-granted to `anon` / `authenticated` /
`service_role`.
This PR decouples the two surfaces:
- **`tableEditorApiAccessToggle`** — unchanged; still gates only the
integrations → Data API settings UI.
- **`dataApiRevokeOnCreateDefault`** (new) — controls only the default
state of the new checkbox at project creation. `true` → checkbox
unchecked by default (revoke runs); `false`/absent → checkbox checked by
default (no behaviour change).
The new flag is already live in PostHog at **0% rollout, off for
everyone**, so shipping this PR changes nothing until the flag is
explicitly flipped.
## Added
- `apps/studio/hooks/misc/useDataApiRevokeOnCreateDefault.ts` — reads
the new PostHog flag. Returns `false` in `IS_TEST_ENV` so existing E2E
flows don't silently change default behaviour.
- Checkbox UI in `SecurityOptions.tsx` (main flow) and
`pages/integrations/vercel/[slug]/deploy-button/new-project.tsx` (Vercel
flow), with copy matching the integrations → Data API settings page.
- Tooltip + dimmed state for the main-flow checkbox when "Enable Data
API" is unchecked (can't configure default privileges if Data API is
off).
- Telemetry: `dataApiDefaultPrivilegesGranted` (raw checkbox value) and
`dataApiRevokeOnCreateDefaultEnabled` (raw flag, conditionally included
using the existing raw-flag pattern so undefined flag state → omitted
property, not `false`).
- Vitest unit tests for the new hook.
## Changed
- `pages/new/[slug].tsx`: removed the `false &&` rollback guard. Revoke
SQL now runs only when `dataApi && !dataApiDefaultPrivileges`. Dropped
the now-unused `useDataApiGrantTogglesEnabled` import.
- `pages/integrations/vercel/[slug]/deploy-button/new-project.tsx`: this
flow was **never rolled back** — it still ran revoke whenever
`tableEditorApiAccessToggle` was on for a user. Now correctly gated on
the new flag + checkbox state.
- `packages/common/telemetry-constants.ts`: added the two new properties
and corrected the `tableEditorApiAccessToggleEnabled` docstring (it no
longer claims to control project-creation revoke behaviour).
## Kill switch
Flipping `dataApiRevokeOnCreateDefault` to off in PostHog fully disables
the revoke SQL for new projects without needing a redeploy — the
checkbox just defaults to checked again.
## Follow-ups (not blockers)
- joshenlim's review comments on PR 43704: (1) Auth Policies table row
incorrectly showing "exposed via Data API" based on schema-level check
instead of table-level at
`apps/studio/components/interfaces/Auth/Policies/PolicyTableRow/index.tsx:64`;
(2) Data API integrations page showing zero exposed tables even after
exposing one. Both unrelated to this PR but will be more visible once
the checkbox lands.
- Once this flag fully rolls out, the old `tableEditorApiAccessToggle`
docstring/comments elsewhere should stop claiming it controls project
creation.
## To test
- **Flag off (default state, simulates post-merge):** create a project
with and without "Enable Data API" checked. The new "Default privileges
for new entities" checkbox should default to **checked**. Submitting
should produce an identical result to today — new tables in `public` are
reachable via the Data API.
- **Flag on (simulate rollout):** override the flag locally. The
checkbox should default to **unchecked**. Creating a project with it
unchecked should run the revoke SQL; create a new table in `public`
afterwards and confirm it's not reachable via the Data API until grants
are added.
- **Enable Data API off:** the new checkbox should render disabled +
dimmed with a tooltip reading "Enable the Data API to configure default
privileges." The revoke SQL should not run in this case regardless of
checkbox state.
- **Vercel flow:** repeat at
`/integrations/vercel/<slug>/deploy-button/new-project` — verify both
checkbox states.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added an "Automatically expose new tables and functions" checkbox to
project creation and Vercel deploy flow; enabled only when Data API is
available (disabled with tooltip otherwise) and affects initial project
provisioning.
* **Telemetry**
* Tracks exposure of the default-privileges control and includes
checkbox state and feature-flag status on project-creation submissions.
* **Tests**
* Added tests for flag behavior, exposure tracking, deduplication, and
submission telemetry.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Co-authored-by: Sean Oliver <882952+seanoliver@users.noreply.github.com>
When high availability is enabled during project creation, automatically
switch to AWS (Revamped) and disable other cloud providers –
multigres/HA is only supported on v3.
<img width="778" height="390" alt="Screenshot 2026-04-06 at 5 09 55 PM"
src="https://github.com/user-attachments/assets/c458f345-497e-4963-9c2f-b4b1eafd030b"
/>
**Changed:**
- Cloud provider selector now watches `highAvailability` form state
- Non-`AWS_K8S` providers (Fly.io, AWS, AWS Nimbus) are disabled when HA
is on
- Warning description shown in orange when HA restricts the provider
choice
**Added:**
- `useEffect` in project creation form to auto-switch cloud provider to
`AWS_K8S` when HA is toggled on
## To test
- Enable the HA toggle on the new project page (requires
`instances.high_availability` entitlement)
- Verify cloud provider auto-switches to AWS (Revamped)
- Verify other providers are greyed out in the dropdown
- Verify orange warning text appears below the cloud provider label
- Toggle HA off and confirm all providers become selectable again
- Ensure project creation still works for both HA and non-HA projects
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* When high availability is enabled, cloud provider selection is
restricted to AWS.
* A warning appears when high availability is enabled, noting AWS-only
support.
* The cloud provider selection automatically switches to AWS if high
availability is toggled on.
* **Bug Fixes**
* Improved form validation to prevent incompatible high-availability and
provider combinations.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
<img width="1196" height="427" alt="image"
src="https://github.com/user-attachments/assets/6784b5e9-99c8-4fc9-b9f5-49672ba6e768"
/>
This reworks the security section within our project creation form to
expose two options.
1/ Enable or disable Data API which is essentially the same as we had
previously, just reframed
2/ Enable auto RLS which creates an event trigger that enables RLS on
all tables created via public schema. This is the same as what we do via
the RLS banner in authentication pages.
Note that this also removes the option to disable Data API on public
schema and move to dedicated schema. The user can still do this post
project creation . Assumption is this is rarely changed on project
creation and adds complexity.
To test:
1. Create a new project
2. Enable Data API and enable RLS setting
3. After project creation, go to triggers -> event tab -> notice enable
rls trigger
4. Create project and disable Data API
5. After project creation , go to settings/api and make sure data api is
disabled
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added an optional automatic Row-Level Security (RLS) event trigger
option in project creation (toggleable via experiment).
* **Improvements**
* Security panel simplified to checkbox-based controls for Data API and
RLS.
* Project creation form now includes the enableRlsEventTrigger flag and
applies related setup when enabled.
* Telemetry records RLS experiment exposure, variant, and whether the
RLS trigger was enabled.
* Free-project messaging updated to consider user limits.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Charis Lam <26616127+charislam@users.noreply.github.com>
Co-authored-by: Sean Oliver <882952+seanoliver@users.noreply.github.com>
* Fix types and lint warnings for the password strength function.
* Simplify the form for creating project. Move the password warning into the form schema. Minor fixes.
* Fix the name of the field.
* Move the common behaviour in a function.
* Minor fixes.
* Break down new project page into smaller components
* Fix types
* Address comments
* Add min length check for project name in project settings
* Fix tests
