Add V2 docs for flyte core deployment

content/oss-deployment/_index.md

@@ -1,6 +1,6 @@
 ---
 title: Platform deployment
-description: Deploy Flyte to your own Kubernetes cluster with the flyte-binary Helm chart.
+description: Deploy Flyte to your own Kubernetes cluster with the flyte-binary or flyte-core Helm chart.
 icon: server
 variants: +flyte -union
 weight: 5
@@ -9,14 +9,17 @@
 
 # Platform deployment
 
-This section covers how to deploy **Flyte** to your own Kubernetes cluster using the
-`flyte-binary` Helm chart.
+This section covers how to deploy **Flyte** to your own Kubernetes cluster.
 
 Flyte ships as a single unified binary that bundles the runs service, the
 task/actions controller, the data proxy, and the app service, served alongside the
 Flyte web console. You point it at three things you provision yourself (a Kubernetes
-cluster, a PostgreSQL database, and an object store) and it runs as one Deployment
-that you scale vertically.
+cluster, a PostgreSQL database, and an object store).
+
+Two Helm charts deploy that binary. The `flyte-binary` chart runs every component in
+one Deployment that you scale vertically — the right choice for most installs. The
+`flyte-core` chart runs one Deployment per component, for when you need to scale,
+schedule, or roll them out independently.
 
 > [!INFO] Try Flyte Devbox in your browser
 >
@@ -35,12 +38,14 @@
    including an optional self-contained authentication setup with
    [Dex](./kind-deployment/local-oidc) (or an
    [external OIDC provider](./kind-deployment/external-oidc)).
-3. [AWS deployment](./aws-deployment): a minimal `values.yaml`, the `helm install`
-   command, object-storage access, ingress, and a worked AWS/EKS example.
+3. [AWS deployment](./aws-deployment/_index): a minimal `values.yaml`, the `helm install`
+   command, object-storage access, ingress, and a worked AWS/EKS example — for
+   [`flyte-binary`](./aws-deployment/flyte-binary) or
+   [`flyte-core`](./aws-deployment/flyte-core).
 4. [Authentication and SSO](./authentication): securing the API and putting single
    sign-on in front of the console.
 5. [Enable app serving](./app-serving): running long-running apps on Knative,
    including how to install the Knative Serving prerequisite.
 6. [Plugin setup](./plugin-setup/_index): cluster-side configuration some plugins need,
    including [copilot's access](./plugin-setup/copilot-storage) to your object store.
 

content/oss-deployment/app-serving.md

@@ -13,27 +13,27 @@
 built-in app controller creates and manages for you, including scaling to zero when an
 app is idle and giving every app a stable URL.
 
 App serving is **off by default**. Because apps depend on Knative, you install Knative
 Serving first, then turn app serving on in the `flyte-binary` chart.
 
 ## How it works
 
 - You define an app (with the SDK) and Flyte's app controller creates a Knative Service
   (`KService`) in your cluster.
 - Knative Serving runs the app, autoscales it (including to zero), and routes traffic.
 - Each app is published at a URL derived from a base domain you configure:
   `{name}-{project}-{domain}.{base-domain}`.
 
 ## Prerequisites
 
-- A running Flyte deployment (see [AWS deployment](./aws-deployment)).
+- A running Flyte deployment (see [AWS deployment](./aws-deployment/_index)).
 - Cluster-admin access to install Knative (CRDs and controllers).
 - A **wildcard DNS record** and a **TLS certificate** for the app base domain (details
   in steps 2 to 3).
 
 {{< note >}}
 Your cloud's ingress/load-balancer controller (for example the AWS Load Balancer
 Controller) **cannot** act as Knative's networking layer. Knative needs one of its own
 networking layers: **Kourier**, Istio, or Contour. This guide uses **Kourier**, the
 lightweight default. You can still place your cloud load balancer *in front of* Kourier
 (see step 3).
@@ -91,7 +91,7 @@
 ```
 
 The single-label template matters: a wildcard TLS certificate (`*.apps.example.com`)
 matches only **one** label. Knative's default template is
 `{{.Name}}.{{.Namespace}}.{{.Domain}}`, which produces a two-label hostname that a
 wildcard certificate would not cover, breaking TLS. Dropping the namespace keeps every
 app hostname single-label.

content/oss-deployment/aws-deployment/_index.md

@@ -0,0 +1,36 @@
+---
+title: AWS deployment
+description: Install Flyte on AWS with either the flyte-binary or the flyte-core Helm chart.
+icon: cloud
+variants: +flyte -union
+weight: 3
+---
+
+# AWS deployment
+
+Flyte ships two charts that deploy the same platform to a real cluster. Both assume
+you have already provisioned the [external dependencies](../overview) — a Kubernetes
+cluster, a PostgreSQL database, and an object-store bucket — and that you have `helm`
+and `kubectl` configured against your cluster.
+
+Pick one:
+
+| Chart | What it deploys | Use it when |
+|---|---|---|
+| [`flyte-binary`](./flyte-binary) | One Deployment running every Flyte component | Most installs. Fewest moving parts, one pod to watch, one config to reason about. |
+| [`flyte-core`](./flyte-core) | The same components split into one Deployment each — runs, actions, events, cache, dataproxy, secret, executor | You need to scale, schedule, or roll out components independently: a hot control plane, a large event volume, per-component node pools or resource limits. |
+
+Both charts read the same underlying Flyte configuration and expose the same API, so
+the choice is about operations, not features. The `flyte-core` guide is written to
+mirror the `flyte-binary` one step for step, so you can compare them side by side.
+
+> [!NOTE] The values schemas are not interchangeable
+> The two charts organize their values differently — `flyte-binary` nests service
+> settings under `flyte-core-components`, `flyte-core` under `configuration` and
+> `components`. A `values.yaml` written for one chart will not install the other.
+> The [`flyte-core` page](./flyte-core#values-differences-from-flyte-binary) lists
+> the differences.
+
+Once Flyte is running, secure it with [Authentication and SSO](../authentication).
+
+{{< subpage-cards >}}

content/oss-deployment/aws-deployment.md → content/oss-deployment/aws-deployment/flyte-binary.md

@@ -1,24 +1,29 @@
 ---
-title: AWS deployment
-description: Install Flyte on AWS with the flyte-binary chart, grant object-store access, and expose it through an ingress.
-icon: cloud
+title: flyte-binary deployment
+description: Install Flyte on AWS as a single Deployment with the flyte-binary chart, grant object-store access, and expose it through an ingress.
+icon: box-seam
 variants: +flyte -union
-weight: 3
+weight: 1
 ---
 
-# AWS deployment
+# flyte-binary deployment
 
-This guide installs Flyte with the `flyte-binary` Helm chart. It assumes you have
-already provisioned the [external dependencies](./overview) (a Kubernetes cluster, a
-PostgreSQL database, and an object-store bucket) and that you have `helm` and
-`kubectl` configured against your cluster.
+This guide installs Flyte with the `flyte-binary` Helm chart, which runs every Flyte
+component in a **single Deployment**. It is the right choice for most installs; if you
+need to scale components independently, use
+[`flyte-core`](./flyte-core) instead.
+
+It assumes you have already provisioned the
+[external dependencies](../overview) (a Kubernetes cluster, a PostgreSQL database, and
+an object-store bucket) and that you have `helm` and `kubectl` configured against your
+cluster.
 
 > [!TIP] Deploy this with an AI assistant
 > [`flyte-agent-plugins`](https://github.com/flyteorg/flyte-agent-plugins) — a
 > portable agent harness plugin for Claude Code, Codex, OpenCode, and other
 > harnesses — includes a `flyte-deploy-aws` skill that provisions a Flyte v2
 > cluster on AWS end to end — EKS + S3 + RDS behind an ALB, with optional TLS and
-> Okta SSO. See [Flyte agent plugins](../api-reference/agent-plugins).
+> Okta SSO. See [Flyte agent plugins](../../api-reference/agent-plugins).
 
 ## 1. Add the Helm repository
 
@@ -153,7 +158,7 @@ configuration:
 By default the chart only creates `ClusterIP` Services. To reach Flyte from outside
 the cluster, enable the ingress. A **single HTTP ingress** serves the console and the
 API. There is no separate gRPC ingress (see the
-[Deployment overview](./overview)).
+[Deployment overview](../overview)).
 
 ```yaml
 ingress:
@@ -170,7 +175,7 @@ the **same ingress host**: always expose them together.
 
 For provider-specific ingress annotations (TLS, ALB scheme, health checks), add them
 under `ingress.httpAnnotations`. See the AWS/EKS example below and the
-[Authentication and SSO](./authentication) page.
+[Authentication and SSO](../authentication) page.
 
 ## 6. Verify the installation
 
@@ -206,16 +211,13 @@ Uninstalling the release removes the ingress resource, which prompts the ingress
 controller (e.g. the AWS Load Balancer Controller) to delete the load balancer it
 provisioned.
 
-{{< WARNING >}}
-Confirm the ALB is gone in the AWS console so it stops billing.
-{{< /WARNING >}}
+> [!WARNING] Confirm the load balancer is gone
+> Check the AWS console that the ALB was actually deleted, so it stops billing.
 
 The external dependencies (the RDS database, the S3 bucket, and the EKS cluster
 itself) are untouched. Delete those separately in the AWS console (or with the tool
 you provisioned them with) if you no longer need them.
 
-Next: secure the deployment with [Authentication and SSO](./authentication).
-
 ## Full Values File Example
 
 A fuller values file for an AWS/EKS cluster: RDS for PostgreSQL, S3 for storage, IRSA
@@ -365,3 +367,5 @@ either:
   `configuration.storage.providerConfig.s3.secretKeyPath` at it.
 
 On the recommended `authType: iam` path there is no storage secret to manage.
+
+Next: secure the deployment with [Authentication and SSO](../authentication).