fix(helm): default web.enabled=true; refocus getting-started on Helm deploy#521
Merged
Merged
Conversation
…deploy
The web frontend is the BFF — the single ingress entry point that proxies
all browser, CLI, and listener traffic to the API. Defaulting web.enabled
to false (while api and listener defaulted true) meant any install with
ingress.enabled=true failed to template ("Ingress is enabled but
web.enabled is false"), including the documented basic install. Enable it
by default so a stock install renders a working stack.
Docs:
- Rewrite getting-started.md around deploying the Helm chart onto a
Kubernetes cluster (or a single-node k3s VM), not the Tilt local-dev
stack: prerequisites, k3s bootstrap, helm install, ingress/DNS access,
API token, first workspace + plan/apply. Verified the install command
renders against the chart.
- Move the Tilt/from-source contributor workflow into a new
local-development.md, linked from getting-started and index.
- Update index.md Quick Start to the Helm one-liner and add the
Local Development nav entry (index + mkdocs).
- Correct the web.enabled default row in deployment.md.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Getting Started read like a local-dev walkthrough (Tilt, mkcert,
make dev) when the actual first-run story is deploy the Helm chart onto a Kubernetes cluster (or a single-node k3s VM). It gave the wrong impression of what Terrapod is and how you run it.While verifying the documented install command against the chart, I hit a real bug: the chart defaults
web.enabled: falsewhileapiandlistenerboth defaulttrue. Since the web frontend is the BFF — the single ingress entry point that proxies all traffic to the API — any install withingress.enabled=truefailed to template:That includes the "Basic Install" example already in
deployment.md. A stock install was never going to render a working stack.Changes
Fix
web.enablednow defaults totrue(consistent withapi/listener; documents the BFF rationale inline). A stockhelm installwith an ingress now renders a complete, working stack.web.enableddefault row indeployment.md.Docs
getting-started.mdaround deploying the Helm chart: prerequisites (k8s 1.27+, external Postgres/Redis), k3s bootstrap for those without a cluster, the verifiedhelm install, ingress/DNS access (+ port-forward fallback), API token, then first workspace + plan/apply.local-development.md, linked from getting-started and index.index.mdQuick Start to the Helm one-liner; added theLocal Developmentnav entry (index.md+mkdocs.yml).Verification
helm lintpasses on bothvalues.yamlandvalues-local.yaml.helm installcommand documented in getting-started renders the web Deployment, Ingress, and bootstrap Job (22 objects).