Skip to main content
This page explains when OpenHands runtime builds may contact anaconda.org and how to avoid it. Why you may still see anaconda.org traffic
  • OpenHands runtime images do not use Anaconda’s defaults channel, so we do not pull packages from Anaconda’s defaults repo.
  • However, conda-forge uses a default channel_alias that expands conda-forge to https://conda.anaconda.org/conda-forge (under the anaconda.org domain).
    • Without overriding channel_alias, you may see network requests to anaconda.org even when you are only installing from conda-forge.
Overview
  • OpenHands runtime images are built with micromamba and we install Python and Poetry from the conda-forge channel
  • Even when using only conda-forge, the default channel_alias expands conda-forge to https://conda.anaconda.org/conda-forge, which is hosted under anaconda.org
Two usage paths
  1. Use prebuilt runtime images
  • No conda network activity occurs during normal use; no contact with anaconda.org on your side
  • If your organization must avoid any anaconda.org contact entirely, build your own runtime image instead (path 2) and configure OpenHands to use it
  1. Build runtime images yourself
  • As of PR #11516, you can override where the conda-forge channel resolves by setting an environment variable before building: export OH_CONDA_CHANNEL_ALIAS=https://repo.prefix.dev

    ​
    then run your standard OpenHands build/run flow that triggers runtime image build

  • With this set, our Dockerfile sets: micromamba config set channel_alias https://repo.prefix.dev
  • We continue to reference -c conda-forge for packages, which will resolve under the configured host (e.g., repo.prefix.dev) instead of anaconda.org
  • You can point channel_alias to:
    • A public alternative such as https://repo.prefix.dev
    • An internal corporate mirror/proxy (e.g., Artifactory) that fronts conda-forge
References