docs: PLTF-388 add Helm-based installer instructions for OpenHands Enterprise#628
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
…undle notes - Note that the no-channel install URL targets the Stable channel; non-Stable licenses must include the channel slug (else 'Channel not found for license') - Add a bring-your-own-certificate values variant alongside the cert-manager one - Document installing the preflight/support-bundle CLIs - Note support-bundle upload prints no link; find the bundle in the portal - Add optional STORAGE_CLASS to the runtime-api values example - Add a troubleshooting row for bundles missing instance metadata
…bleshooting - Drop the claim that self-signed certs break login/agent comms (chart support for self-signed is being explored separately) - Remove the publicly-trusted absolute from the BYO-cert note - Drop the Pending/no-default-storage-class row (a default storage class is already a stated prerequisite)
Co-authored-by: openhands <openhands@all-hands.dev>
Co-authored-by: openhands <openhands@all-hands.dev>
…-helm-based-installer
Add postgresql.auth.database, databaseMigrations.createDatabases (app + runtime-api), and litellm-helm.enabled — without these the bundled-DB path hangs at wait-for-db and no LiteLLM deploys. Correct the 'no configuration needed' prose.
keycloak.enabled defaults false in the chart; the example configured only the Keycloak ingress, so no Keycloak was deployed and login dead-ended with a 404 on auth.app.<domain>. Verified on a fresh KinD install: without this flag no keycloak pod renders; with it the auth endpoints come up and the GitHub login redirect returns 303.
The runtime-api chart defaults STORAGE_CLASS to standard-rwo, which only exists on GKE. On any other cluster sandbox PVCs stay Pending on the nonexistent class and every sandbox times out at startup. Verified live: with the default, PVCs never bind; setting the cluster's storage class makes sandboxes start. Replace the optional (and incorrect) comment with an explicit setting.
| - **LLM credentials** from your chosen provider, for example an Anthropic API key | ||
| from the [Anthropic Console](https://console.anthropic.com/) | ||
| - DNS records you control, following the `app.<base-domain>` layout used | ||
| throughout this guide (with `openhands.example.com` as the base): | ||
| `app.openhands.example.com` (application), `auth.app.openhands.example.com` | ||
| (login), `runtime-api.openhands.example.com`, and a **wildcard** | ||
| `*.runtime.openhands.example.com` for runtime sandboxes. These point at your | ||
| cluster's ingress; see the Quick Start's | ||
| [DNS checks](/enterprise/quick-start#dns-checks) for the full hostname list. | ||
| - **TLS certificates covering all of the hostnames above**, which you provide. |
There was a problem hiding this comment.
Non-blocking followup: We should probably give some guidance around using cert-manager and external-dns. Some instructions for these tools (which are super common) will also help provide examples that will inform consumers on customizing their install to use other tools we haven't considered yet.
There was a problem hiding this comment.
I was thinking it would be good to have cert manager as a follow up example!
There was a problem hiding this comment.
I can get some linear issues created
| The chart references several Kubernetes secrets that you create ahead of installation: | ||
|
|
||
| ```bash | ||
| kubectl create namespace openhands |
There was a problem hiding this comment.
I'm not sure where (or if) the runtime namespace is exposed in the charts, but we should instruct consumers to run sandboxes in a separate namespace from the other workloads deployed by this chart.
|
|
||
| ## Step 5: Validate the installation | ||
|
|
||
| The chart ships preflight checks that validate your cluster against the |
Address PR #628 review comment: link the Replicated trial signup page (https://install.r9.all-hands.dev/openhands/signup) in the license Note on the Helm-based installation page. Co-authored-by: openhands <openhands@all-hands.dev>
Update the Helm-based installer prerequisites to require Helm v4 or later (prerequisite list and troubleshooting table), aligning with the embedded cluster's Helm version and Helm v3's upcoming EOL. Co-authored-by: openhands <openhands@all-hands.dev>
… path Address review feedback: add a Warning to the K8s install page clarifying that the embedded PostgreSQL is for proof-of-concept/evaluation only (not production), that we recommend an external database, and that there is no officially supported migration path from the embedded instance to an external one. Co-authored-by: openhands <openhands@all-hands.dev>
…-helm-based-installer
Why
Adds a new page
enterprise/k8s-install/installation.mdx("Install with Helm") for the OHE Helm Install path with Replicated, wired into the K8s Install nav and linked from the overview page: registry login with license credentials, the secrets the chart expects (GitHub App via the existing creation script;allhandsrealm/client naming), a minimal usable values file (ingress + keycloak ingress, runtime endpoints withRUNTIME_BASE_URL/RUNTIME_DISABLE_SSL, embedded PostgreSQL/Redis/MinIO), install, preflight, and support-bundle generation + upload. Prerequisites such as DNS hostnames and certificates. A Next Steps section establishes the pattern that features and sizing arehelm upgradeoverrides documented on their own pages; thehelm upgradeexamples inanalytics.mdxandplugin-marketplace.mdxnow use the Replicated registry chart URL so upgrades reference the same source as the install.Validation
openhands 0.24.0via the documented install URL): licensed registry pull, GitHub App login through keycloak, sandbox start, and a working agent conversation. Preflight passed from the in-cluster Secret; an earlier run (chart 0.23.1) uploaded a support bundle confirmed present in the Vendor Portal.helm template.This PR was drafted by an AI agent on behalf of the user.