[unionai-docsy-agent]

Adds a "Horizontal autoscaling" subsection to the flyte-core deployment page, at the end of "Scaling and scheduling individual components". It covers the opt-in HorizontalPodAutoscaler support that flyteorg/flyte#8158 added to the chart. The executor warning now also says the executor has no autoscaling. Everything comes from reading the chart source at the v2.0.52 tag. I could not render the chart: helm isn't installed here, and the sandbox blocks network tools.

Re-applied edits: when I started this revision, the working tree held none of the earlier draft's page edits. Only the pre-existing SVG mode change was there. I wrote the edits again against the source, with the reviewer's findings included.

What changed in the product, and which signals asked for docs

flyteorg/flyte#8158, "Add support for HPAs to flyte-core helm chart", was opened on 2026-10-09 (signal 830) and merged on 2026-10-13 (signal 993). It adds an autoscaling block to most flyte-core components. When the block is enabled, the chart renders an autoscaling/v2 HorizontalPodAutoscaler for that component. It is off by default.

Release: the v2.0.52 tag is d95058da. That is the commit checked out in sources/flyte, and its tree contains charts/flyte-core/templates/*/hpa.yaml. I resolved the tag in the previous round. I couldn't re-check it this round, because network tools are blocked. The owner's note of 2026-10-20 says v2.0.51 does not contain #8158.

Two corrections to the brief

• The page already exists. The brief said no page documents the flyte-core values. content/oss-deployment/aws-deployment/flyte-core.md (Flyte variant only) does, and it already has a scaling section, so I extended that page.
• The component list was slightly off.
  • The console's values are at console.autoscaling, not components.console.autoscaling.
  • secret also gets an autoscaler.
  • executor does not.

Changes to content/oss-deployment/aws-deployment/flyte-core.md

• New ### Horizontal autoscaling subsection:
  • Which components support it, and that it's off by default.
  • Where the values live; for app, the component itself must also be enabled.
  • The chart-version requirement, with a helm repo update / helm search repo check.
  • A values-only YAML snippet.
  • A table of keys and defaults.
  • replicaCount is ignored while autoscaling is on.
  • When rendering fails.
• Executor warning: says "no replicaCount and no autoscaling".

Evidence (flyte d95058da, charts/flyte-core/)

• Components: templates/{runs,actions,events,secret,cache,app,dataproxy,console}/hpa.yaml exist; there is none under executor/. executor/deployment.yaml hardcodes replicas: 1. console/hpa.yaml reads $.Values.console.
• Defaults (values.yaml, the same for every component and console): enabled: false, minReplicas: 1, maxReplicas: 10, targetCPUUtilizationPercentage: 80, targetMemoryUtilizationPercentage: null, metrics: [], behavior: {}. The comments say "Resource utilization requires resource requests" and list the metric types as "Pods, Object, External, or Resource".
• Metrics order: hpa.yaml emits the CPU metric under with, then the memory metric under with, then toYaml of metrics. The CPU metric appears whenever its target is set, and the default is 80.
• Behavior: with $autoscaling.behavior is followed by toYaml.
• replicaCount ignored: each deployment.yaml, including the console's, wraps replicas: in if not ...autoscaling.enabled.
• app must be enabled: each hpa.yaml is gated on if and $component.enabled $autoscaling.enabled.
• Rendering failures:
  • fail "...: require 1 <= minReplicas <= maxReplicas"
  • fail "...: configure at least one metric" when the CPU target, the memory target and metrics are all unset.
• Chart version string: publish-helm.yml runs on v2* tags, with VERSION: ${{ github.ref_name }}. scripts/tag-helm.sh writes ${VERSION} into Chart.yaml version:, so the published chart version is v2.0.52, with the v. The page uses that form.
• Silently ignored on older charts: the chart has no values.schema.json, so Helm doesn't reject unknown keys. Older charts have no hpa.yaml and no replicas gate, so the values do nothing. I could only see the v2.0.52 tree; the shallow clone doesn't contain v2.0.51.

Reviewer findings

• Version gate stated as fact while the description doubts it (line 446): taken. I still can't confirm the publish run succeeded or that the index lists the version. Per the rule that an unsettled condition goes on the page, the page now gives the requirement as a condition the reader checks: run helm repo update, then confirm that helm search repo flyteorg/flyte-core --versions lists v2.0.52 or later. The requirement itself is settled: the feature exists only from the v2.0.52 tag on.
• Older charts silently ignore the values: taken, using your suggested wording, merged into the sentence above.
• CPU target stays with custom metrics (line 469): taken, using your suggested row text. I verified it against hpa.yaml and the 80 default. The rendering-failure note was changed to match.
• Question: is the chart version v2.0.52 or 2.0.52? Answered from source: it is v2.0.52, because VERSION is github.ref_name. Whether the publish run succeeded is still open (below).

Open questions, answered in session

• Was the chart published? Yes. helm search repo flyteorg/flyte-core --versions lists v2.0.52, v2.0.53 and v2.0.54.
• Rendered (Peeter Piegaze, 2026-11-06): helm pull flyteorg/flyte-core --version 2.0.52, then helm template:
  • --set components.actions.autoscaling.enabled=true renders an HPA for actions (min 1, max 10, one Resource CPU metric at 80%), and the actions Deployment has no replicas.
  • values.yaml has resources: {} for every component, so that Deployment's container has no requests.
  • minReplicas=0 fails with actions.autoscaling: require 1 <= minReplicas <= maxReplicas; targetCPUUtilizationPercentage=null alone fails with actions.autoscaling: configure at least one metric.
  • templates/*/hpa.yaml exists for exactly the eight components the page lists, and not for executor.

Revised in session (Peeter Piegaze, 7d5ff08)

Docsy's pre-flight gotchas, now on the page as a "Before you turn it on" list at the end of the subsection:

• Set resource requests. From the render above: with the default resources: {} the HPA has no request to compute utilization against, so it never scales.
• Install a metrics source. CPU and memory targets read the Kubernetes metrics API, which needs metrics-server, and EKS doesn't install it by default.
• Expect a brief drop when switching an existing release. Enabling autoscaling removes replicas from the Deployment, which falls back to the default of one replica until the HPA scales up. The Kubernetes docs warn about this when migrating a Deployment to an HPA. Not reproduced on a live cluster.
• Per-component key list near the top of the section now includes autoscaling, with a link to the subsection.

Note

The working tree also shows a mode change (100755 → 100644) on content/_static/images/deployment/flyte_wf_timeline.svg. It was already in the checkout and is not part of this change. Don't commit it.

docsy left out changes outside the pages a draft may change: content/_static/images/deployment/flyte_wf_timeline.svg.

Pre-flight review

docsy's reviewer read the first draft before it was opened and made 5 findings. The draft was revised twice in response; its last check still made 5 findings. Its summary of the first draft:

The content is accurate against the flyte-core chart on flyteorg/flyte main. One fix is needed before merge: the version gate.

• Version gate (line 431): the release that introduces the feature isn't verified. The page states "From Flyte v2.0.52" unconditionally, but the description itself couldn't confirm that the v2.0.52 chart is published. Restate it as a chart-version requirement, as the style guide asks, and confirm the release (see question).
• Rendering-failure note (line 459): "no metric is configured" can't happen with the defaults, because the CPU target defaults to 80. Say when it does happen.
• Metrics row (line 455): the wording "the two above" is loose, because the memory target is unset by default.

I couldn't verify the v2.0.52 tag or the Helm index: the source clone is shallow and network access was blocked. I didn't run helm template either.

---

Docsy case 830: https://docsy.apps.demo.hosted.unionai.cloud/cases/830

_{Drafted by Docsy, Union.ai's documentation agent, from the product changes and requests in this case. Review it like any PR; close it if it's not wanted.}

[github-actions]

GHA build & deploy preview

Built by .github/workflows/build-pr.yml and deployed to the docs CF Pages project by .github/workflows/deploy-pr-preview.yml.

Branch alias	https://pr-1774-docsy-case-830.docs-dog.pages.dev
This commit	https://b8de998a.docs-dog.pages.dev
Commit SHA	7d5ff08f2cda85f1bbc4603c3fdc034a530a4258

Updated automatically on every push.

[unionai-docsy-agent]

Docsy actions: what Docsy did on this PR, and at whose direction. Docsy adds a line for each.

• 2026-11-06 17:21 UTC · pushed 7d5ff08, an edit: Add the autoscaling gotchas from Docsy's pre-flight, checked by rendering flyte-core v2.0.52 (resources default to {}, autoscaling drops replicas from the Deployment, the HPA uses a Resource CPU target), and list autoscaling among the per-component keys. · at the direction of Peeter Piegaze (ppiegaze)
• 2026-11-06 17:21 UTC · changed the description · at the direction of Peeter Piegaze (ppiegaze)