You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi OpenHands Team,
We are attempting to run OpenHands v0.38 locally in Docker, configured to use our own Daytona SaaS account as the runtime provider. We have been following the official documentation for Daytona Runtime integration: https://docs.all-hands.dev/modules/usage/runtimes/daytona.
Following Step 3 in the documentation, we initially used the provided script: bash -i <(curl -sL https://get.daytona.io/openhands). However, we noticed this script pulls an older version of OpenHands (v0.31) and its corresponding runtime (runtime:0.31-nikolaik), which was not stable for our use.
To use the latest OpenHands v0.38, we adapted the Docker command by:
Using docker.all-hands.dev/all-hands-ai/openhands:0.38 as the main image.
Setting RUNTIME=daytona.
Providing our valid DAYTONA_API_KEY from our Daytona SaaS dashboard.
Setting SANDBOX_RUNTIME_CONTAINER_IMAGE initially to docker.all-hands.dev/all-hands-ai/runtime:0.38-nikolaik (as suggested by the non-Daytona v0.38 setup docs).
With this v0.38 configuration, the main OpenHands container starts successfully. However, when OpenHands (via the Daytona SDK) instructs our Daytona SaaS account to create a sandbox, we consistently encounter the error:
daytona_sdk.common.errors.DaytonaError: Failed to create sandbox: Image docker.all-hands.dev/all-hands-ai/runtime:0.38-nikolaik not found or not accessible
We also tried setting SANDBOX_RUNTIME_CONTAINER_IMAGE to docker.all-hands.dev/all-hands-ai/runtime:0.38 (without the -nikolaik suffix), but our Daytona SaaS platform still reports the same "Image not found or not accessible" error when trying to create the sandbox.
For context, running OpenHands v0.38 with the local Docker runtime (by mounting /var/run/docker.sock and not setting RUNTIME=daytona) works correctly on our local machine with the runtime:0.38-nikolaik image. This suggests the images themselves are valid, but our Daytona SaaS account is unable to pull them from docker.all-hands.dev.
Could you please clarify the following for using OpenHands v0.38 with a user-provided Daytona SaaS account as the runtime, considering the official documentation:
What is the exact and official SANDBOX_RUNTIME_CONTAINER_IMAGE (name and tag) that should be specified for OpenHands v0.38 when using RUNTIME=daytona? (The get.daytona.io/openhands script seems outdated for v0.38).
Is docker.all-hands.dev a private Docker registry?
If it is a private registry (or requires specific access), how can users ensure their Daytona SaaS platform is authorized or able to pull the necessary runtime images from docker.all-hands.dev to create sandboxes? Is there any configuration needed on the Daytona SaaS side, or should we be using a different, publicly accessible runtime image for this setup?
We believe the core issue is the inability of the Daytona SaaS platform (acting on behalf of our account) to access the specified runtime image from docker.all-hands.dev when trying to follow the Daytona runtime guide with OpenHands v0.38.
Any guidance on the correct runtime image for v0.38 with Daytona SaaS, or how to enable image access, would be extremely helpful.
Thank you for your support!
The text was updated successfully, but these errors were encountered:
Going to ping @idagelic because I think they added all of the docs around this and are from Daytona. Might be good to reach out to their org directly as well.
Hi OpenHands Team,
We are attempting to run OpenHands v0.38 locally in Docker, configured to use our own Daytona SaaS account as the runtime provider. We have been following the official documentation for Daytona Runtime integration: https://docs.all-hands.dev/modules/usage/runtimes/daytona.
Following Step 3 in the documentation, we initially used the provided script: bash -i <(curl -sL https://get.daytona.io/openhands). However, we noticed this script pulls an older version of OpenHands (v0.31) and its corresponding runtime (runtime:0.31-nikolaik), which was not stable for our use.
To use the latest OpenHands v0.38, we adapted the Docker command by:
Using docker.all-hands.dev/all-hands-ai/openhands:0.38 as the main image.
Setting RUNTIME=daytona.
Providing our valid DAYTONA_API_KEY from our Daytona SaaS dashboard.
Setting SANDBOX_RUNTIME_CONTAINER_IMAGE initially to docker.all-hands.dev/all-hands-ai/runtime:0.38-nikolaik (as suggested by the non-Daytona v0.38 setup docs).
With this v0.38 configuration, the main OpenHands container starts successfully. However, when OpenHands (via the Daytona SDK) instructs our Daytona SaaS account to create a sandbox, we consistently encounter the error:
daytona_sdk.common.errors.DaytonaError: Failed to create sandbox: Image docker.all-hands.dev/all-hands-ai/runtime:0.38-nikolaik not found or not accessible
We also tried setting SANDBOX_RUNTIME_CONTAINER_IMAGE to docker.all-hands.dev/all-hands-ai/runtime:0.38 (without the -nikolaik suffix), but our Daytona SaaS platform still reports the same "Image not found or not accessible" error when trying to create the sandbox.
For context, running OpenHands v0.38 with the local Docker runtime (by mounting /var/run/docker.sock and not setting RUNTIME=daytona) works correctly on our local machine with the runtime:0.38-nikolaik image. This suggests the images themselves are valid, but our Daytona SaaS account is unable to pull them from docker.all-hands.dev.
Could you please clarify the following for using OpenHands v0.38 with a user-provided Daytona SaaS account as the runtime, considering the official documentation:
What is the exact and official SANDBOX_RUNTIME_CONTAINER_IMAGE (name and tag) that should be specified for OpenHands v0.38 when using RUNTIME=daytona? (The get.daytona.io/openhands script seems outdated for v0.38).
Is docker.all-hands.dev a private Docker registry?
If it is a private registry (or requires specific access), how can users ensure their Daytona SaaS platform is authorized or able to pull the necessary runtime images from docker.all-hands.dev to create sandboxes? Is there any configuration needed on the Daytona SaaS side, or should we be using a different, publicly accessible runtime image for this setup?
We believe the core issue is the inability of the Daytona SaaS platform (acting on behalf of our account) to access the specified runtime image from docker.all-hands.dev when trying to follow the Daytona runtime guide with OpenHands v0.38.
Any guidance on the correct runtime image for v0.38 with Daytona SaaS, or how to enable image access, would be extremely helpful.
Thank you for your support!
The text was updated successfully, but these errors were encountered: