Files
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
..

Writing components

Where to create your components

  • For components that declare the general structure and layout of a page:
    • /components/layouts/xxx
  • For components that are tightly coupled to a specific interface:
    • /components/interfaces/xxx
  • For components that are meant to be reusable across multiple pages:
    • /components/ui/xxx
  • Note: We're gradually moving files out of the to-be-cleaned folder into the respective folders as we refactor

Component structure

  • If a component has constants and utility methods that are tightly coupled to itself, keep them close to the component and enclose them in a folder with an index.tsx as an entry point
  • Otherwise it can just be a file on its own
  • For example:
    • components/ui
      - SampleComponentA
        - SampleComponentA.tsx
        - SampleComponentA.constants.ts
        - SampleComponentA.utils.ts
        - SampleComponentA.types.ts
        - index.ts
      - SampleComponentB.tsx
      

Template for building components


// Declare the prop types of your component
interface ComponentAProps {
  sampleProp: string
}

// Name your component accordingly — use a named export, not a default export
export const ComponentA = ({ sampleProp }: ComponentAProps) => {
  return <div>ComponentA: {sampleProp}</div>
}