Hello team , I’m trying to set up the enterprise server locally and could use some guidance. I was advised by @millions-afternoon-47582 to follow the enterprise docs, but I believe they’re slightly outdated: https://github.com/OpenHands/OpenHands/tree/main/enterprise/enterprise_local What I’ve done so far I was able to figure out most of the setup on my own, but I ran into issues at this step: 1.

decrypt_env.sh

step The docs mention running

local/decrypt_env.sh

, but they don’t specify that a path argument is required. From the script itself:

enterprise_local/decrypt_env.sh <DEPLOY_DIR>
Example: enterprise_local/decrypt_env.sh /path/to/deploy

Since this wasn’t mentioned in the docs and I wasn’t sure what path to pass, I skipped this step. 2. Error while running

convert_to_env.py

After that, I ran:

python enterprise_local/convert_to_env.py

And got the following error:

Error: [Errno 2] No such file or directory: 'github_decrypted.yaml'

Traceback (most recent call last):
  File ".../enterprise_local/convert_to_env.py", line 87, in <module>
    os.remove(yaml_file)
FileNotFoundError: [Errno 2] No such file or directory: 'github_decrypted.yaml'

I assume this file should have been generated by the skipped

decrypt_env.sh

step, but I’m not fully sure. Context about my PR I’ve opened a PR here: https://github.com/OpenHands/OpenHands/pull/12181 I tested everything up to the point where clicking the GitHub auth button redirects to GitHub. However, after the redirect, the server was still running in OSS mode, so I couldn’t complete the OAuth flow end-to-end and fully validate the PR. My questions What exactly am I doing wrong in the enterprise local setup? 1. What should the correct

DEPLOY_DIR

be for

decrypt_env.sh

? 2. Is there a recommended way to fully run the enterprise server locally so GitHub auth can be tested end-to-end? 3. Is there anything else I should configure before testing OAuth for enterprise mode? Any help or pointers would be really appreciated. Thanks a lot!

cc @quick-window-91705, @straight-sundown-84319

Thanks for the detailed report!

Things got a bit messed up when we moved everything to the openhands repo. The deploy repo still has the secrets (which are not publicly available), so the DEPLOY_DIR needs to point to the location of the deploy repo. But looking at the script, it is not correct. I'll update it. But I don't think @echoing-ability-9927 will have access to these secrets (they point to our staging github app and keycloak instances). He will have to create a github app and run a keycloak instance in order for this to work. I can create a doc on how to do this if we think we need it @wooden-umbrella-84098. Another option is to use the OpenHands-Cloud repo to install on a local kubernetes. @echoing-ability-9927, do you want to run it locally in an IDE or just have a local installation?

I would use openhands-cloud, I think that's our official path

Here's the readme for openhands helm chart: https://github.com/All-Hands-AI/OpenHands-Cloud/blob/main/charts/openhands/README.md

@wooden-umbrella-84098, @flaky-jordan-67349 My main goal is to test the GitHub authentication flow end-to-end so I can confidently complete and validate the PR I opened. I don’t specifically need the full enterprise stack beyond what’s required for auth to work correctly. If

openhands-cloud

is the official and recommended path, I’m happy to go that route. Running it locally (even via a local Kubernetes setup) is totally fine for me as long as I can complete the OAuth flow end-to-end. I initially tried running things directly in an IDE because it felt simpler for iterating on the PR, but I’m flexible — whatever setup allows proper GitHub auth testing locally works for me. If there’s existing guidance for using

openhands-cloud

locally for auth testing, I’ll follow that. Thanks a lot for the help

Yeah it's unfortunately a very complicated setup 😞

He is currently working on the new login page. This is his pull request: https://github.com/OpenHands/OpenHands/pull/12181. He needs to run his code in SaaS mode to verify his work thankyou

We could test it on a feature stack.

yeah that's probably the best! I think we can tag his PR to kick off a feature deploy

Yes, but it appears that adding the “deploy” label no longer works. He will need access to the deploy repository to proceed, but that repository is private. Additionally, I am not certain that the deploy repository will function correctly with a pull request created from a forked repository.

hmm maybe we can make an internal branch based on his?

Yes, there is a scenario where, after verifying his work, he finds some issues and wants to update his code. If I understand correctly, he cannot push his changes to our internal branch because he does not have write access to the main repository.

yes, i do not have the access to the repository to push the branch

This should help fix deploy preview: https://github.com/OpenHands/OpenHands/pull/12216 If a docker image builds from a fork then it should be good enough to kick off a feature stack The only problem is our oauth guard on staging

@freezing-spoon-14104 @millions-afternoon-47582 Would love to get a review on this pr https://github.com/OpenHands/OpenHands/pull/12181 I mocked the backend with the auth could you please take a look and lmk if anything i'm missing

I will review the pull request. Thank you! thankyou