feat: wire Agent Canvas through Replicated/Helm installs

[lilagrc]

Summary

Agent Canvas (the /canvas UI) was added to the Helm chart in #900 — the agent-canvas subchart, the templates/ingress-agent-canvas.yaml umbrella ingress, and an agent-canvas: block in charts/openhands/values.yaml. However, that PR never touched replicated/, so the feature was never wired into the Replicated (KOTS) release. Replicated installs (and Helm installs derived from the KOTS values) are driven by replicated/openhands.yaml, which had zero agent-canvas configuration, so the subchart stayed at its enabled: false default and never deployed. There was also no config toggle, no status informers, and no airgap image-bundling entry.

A latent bug compounded this: the subchart's image.tag defaulted to "", so even a bare agent-canvas.enabled: true would render an invalid image reference (ghcr.io/openhands/agent-canvas:) and fail to pull.

This PR wires Agent Canvas all the way through to Replicated/Helm customers.

Changes

• charts/openhands/charts/agent-canvas/values.yaml — pin a real default image.tag (sha-ef3b28a, the current main build; digest-verified against the ghcr main tag) so the chart is deployable on its own. The OpenHands Cloud deploy workflow still overrides this at deploy time. agent-canvas only publishes sha-/pr- tags (no semver), so this tracks a known-good main build.
• replicated/config.yaml — add an agent_canvas_configuration group with an agent_canvas_enabled bool. Defaulted on so it ships to customers, but is a clean opt-out.
• replicated/openhands.yaml —
  • add an optionalValues block (gated on agent_canvas_enabled) that enables the subchart, points the image at the licensed proxy registry, adds the image pull secret, enables the ingress on the primary app host at /canvas with the existing openhands-tls secret, and sets staticServer.lockToCloud to the instance's own app URL (so the Canvas UI targets the customer's backend, not all-hands.dev);
  • add agent-canvas to the builder block for airgap image bundling.
• replicated/application.yaml — add conditional statusInformers for the agent-canvas deployment, service, and ingress.
• charts/openhands/tests/agent_canvas_ingress_test.yaml — new helm-unittest suite covering disabled cases, /canvas routing, TLS on/off, and the required-host failure.

Validation

• helm unittest charts/openhands -> 31 passed (including 5 new agent-canvas tests).
• make manifests builds all Replicated manifests cleanly with the canvas wiring present.
• All edited replicated/*.yaml files parse as valid YAML.
• Subchart deployment now renders a valid image (ghcr.io/openhands/agent-canvas:sha-ef3b28a) and correct --base-path / --lock-to-cloud / --auth-required args.

Notes / open questions

• Default-on vs opt-in: agent_canvas_enabled defaults to "1" to satisfy "available all the way through to customers." If you'd prefer opt-in like plugin-directory ("0"), that's a one-line change.
• Image tag pinning: there's no automated image-tag-bump workflow wiring agent-canvas into this repo, so the pinned default needs manual bumps (or a new bump-workflow caller) unless the deploy workflow always overrides it. A follow-up to add semver releases or an auto-bump for agent-canvas may be worthwhile.
• Same-host routing: Canvas shares the app host and relies on Traefik longest-prefix routing (/canvas -> canvas, / -> app), matching production app.all-hands.dev/canvas.

---

This PR was created by an AI agent (OpenHands) on behalf of the user.

[lilagrc]

Initial code review (via /codereview repo skill)

Reviewed against the repo's code-review guidelines. Overall this follows the established Replicated wiring patterns well — the optionalValues block, statusInformers, builder entry, and config toggle all mirror plugin-directory and automation. No blocking (important+) issues found. A few points worth a decision before this leaves draft:

1. Default-on vs. opt-in (guideline #7: "Defaults serve the self-hosted user") — most substantive

agent_canvas_enabled defaults to "1", whereas the comparable feature toggles plugin_directory_enabled and automations_enabled both default to "0". Enabling a relatively new preview UI by default for every self-hosted/Replicated user is a notable posture change. Unless there's a product decision to ship Canvas on by default, defaulting to "0" would be more consistent with the other optional components and safer for self-hosted users. (Flagged in the PR description as an open question.)

2. TLS secret name is inconsistent with the other chart ingresses

The Canvas ingress uses secretName: openhands-tls, but every other ingress in the openhands chart (ingress-root, -mcp, -automation, -integrations-hub, -plugin-directory) uses app-all-hands-{{ .Values.tls.env }}-tls. Both secrets are created with the same cert by openhands-secrets/templates/tls-certificate.yaml, so this is functional, not a bug — but the inconsistency is a small future-maintenance trap. Consider aligning Canvas with the same app-all-hands-<env>-tls secret the sibling ingresses use. (The agent-canvas ingress template takes an explicit secretName, so this is purely a value choice in replicated/openhands.yaml.)

3. Pinned sha- image tag will go stale

The replicated block overrides image.repository but intentionally inherits image.tag from the subchart default (sha-ef3b28a). Because agent-canvas only publishes sha-/pr- tags and there's no image-tag-bump workflow wiring it into this repo, this pin will drift over time unless the deploy workflow always overrides it or a bump automation is added. Worth confirming the intended source of truth for the Canvas tag and whether a follow-up (semver releases or an auto-bump caller) should track it.

4. Config grouping (minor)

plugin_directory_enabled lives under the Experimental group ("Preview features … Enable at your own risk"). If Canvas is still preview-quality, placing agent_canvas_enabled there rather than in a new dedicated group may set clearer expectations; if it's considered GA, a standalone group is fine.

Nits

• None blocking. The comments on the optionalValues block and image tag are clear and helpful.

Tests and build validation look solid (helm unittest 31 passed incl. the new ingress suite; make manifests builds cleanly).

---

This review was generated by an AI agent (OpenHands) on behalf of the user.