Hi, I deployed OpenHands in our own infrastructure following these guides: • https://github.com/All-Hands-AI/OpenHands-Cloud/tree/main/terraform/aws • https://docs.openhands.dev/enterprise/quick-start The deployment is up and running, and overall everything seems to work well. However, I’m struggling to understand how the deployment is actually managed under the hood. From what I can tell, the setup runs a Kubernetes cluster on the EC2 instance. Using

kubectl

, I can inspect the pods and resources without issues. What’s unclear to me is how to customize Helm values after deployment. For example, I’d like to set:

RUNTIME_CLASS: "sysbox-runc"

as shown here: https://github.com/All-Hands-AI/OpenHands-Cloud/blob/9f05a50b819caa553752efeb0354c69619de3bc1/charts/runtime-api/values.yaml#L53 I struggle to understand how changes like this are meant to be applied in the deployed environment. I’m familiar with Kubernetes and Helm, but the admin UI is breaking my usual mental model of how the system is managed. Normally I’d expect some

helm upgrade

/

helm template

+

kubectl apply

workflow, but I can’t tell: • where the Helm releases are managed, • whether the UI writes back to Helm values, • or how manual configuration changes should be applied and persisted. Any hints are much appreciated. Thanks!

Hi! Great question — the piece that's missing from your mental model is that the installer is built on Replicated/KOTS, which sits in front of Helm and owns the release lifecycle. So the usual

helm upgrade

loop isn't the right entry point here; KOTS is what reconciles state onto the cluster. How it actually works under the hood: - KOTS stores your config (the values you set in the admin UI) as a versioned application config. - On deploy, KOTS renders the Helm charts with those values plus its own templating, and applies the result to the cluster. - Any change you make in the admin UI creates a new version that you then deploy — that's the equivalent of

helm upgrade

in this world. - If you

helm upgrade

or

kubectl apply

directly, KOTS will overwrite your changes on the next deploy, so don't go that route. For the specific case of

RUNTIME_CLASS: "sysbox-runc"

on the runtime-api chart: that value isn't exposed as a first-class field in the admin UI today. The way to set arbitrary Helm values that we don't surface directly is through the Config screen in the KOTS admin console — there's a section for advanced/custom Helm values that gets merged into the chart values at render time. Set it there, save, and then deploy the new version from the Version history tab. After it deploys you can confirm with

kubectl get pods -n <ns> -o yaml

that the runtimeClassName landed where you expect. A couple of things worth flagging: -

sysbox-runc

requires the Sysbox runtime to actually be installed on the node and registered as a RuntimeClass in the cluster. The embedded installer runs k0s on the EC2 instance and doesn't ship Sysbox by default, so you'll need to install it on the host and create the RuntimeClass resource before the value will do anything useful. Happy to dig into that with you if it's not already set up. - If the value you want to override isn't reachable from the admin UI's custom values section, let me know which one and we can either expose it or give you a workaround. Let me know how it goes!

Yes the missing piece is the Replicated config. Those configs get set as k8s secrets via the openhands-secrets helm chart. We then reference those k8s secrets in our openhands chart templates. We also have Replicated wrapper helm charts to set values from the Replicated config options

Thanks both of you for the quick reply. So the best/easiest option is to get onto the

sysbox

release channel? It seems like this would take care of all the details @wooden-umbrella-84098 mentioned above which is great. However I’m not ready for such disruptive actions as I just share the OH instance with a few folks to tinker. Maybe later this week. What is the process to get onto the channel, open a support ticket via https://install.r9.all-hands.dev/openhands/support?

Yes getting onto the

sysbox

release channel would be the easiest. It is in beta as it is a tricky setup with additional install scripts. I think you can ping us in this thread when you are ready! CC @average-processor-75195 on the support ticket process

Thanks I’m on the sysbox release channel and it works. However I would like to set other arbitrary helm values such as {{ .Values.runtime.image.tag }} I’m unable to find the mentioned section in the KOTS Admin Console or am I looking in the wrong place?

there’s a section for advanced/custom Helm values that gets merged into the chart values at render time.