Skip to content
For Self-Managed AI Platform users running v11.1, see the on-premise platform documentation
Self-managed installation and maintenance > Installation and configuration guide > DataRobot advanced configuration section > Custom Applications

Custom Applications

Enabling the service

Support for custom applications is enabled by default.

Requirements

The [DataRobot] Python 3.12 Applications Base and [DataRobot] NodeJS 22.14.0 Applications Base are required for running custom applications from templates. They are installed as part of the Custom Templates Job.

Note! When upgrading DataRobot versions, these execution environments are not automatically upgraded to the latest versions. In order to receive the latest updates it is necessary to ensure that the execution environment upgrade step is carried out during the DataRobot upgrade procedure.

Testing the service

There are generally three ways of testing custom applications:

  1. There is an e2e folder in custom applications repo. There's a skipped test where you can use an API key + URL for that env (You'll need the feature flag named below), or you can use the existing test and have that create a new user if you like.
  2. You can enable Enable Execution Environments from Prebuilt Images feature flag, follow the instructions to build an example app (eg the example streamlit app: https://github.com/datarobot/custom-apps-streamlit), go to the /applications page on DataRobot, click the Use Template button under Custom, and follow the instructions to upload an app. There is an example custom app in the custom apps e2e test folder called hello-custom-app.tar which uploads quickly.
  3. Alternatively, you can set up DR Apps (https://github.com/datarobot/dr-apps), and upload one of the example applications

Things of note

  1. The custom applications proxy uses Sushi to send requests to / from DataRobot.
  2. External Sharing requires the SMTP server to be set up properly.
  3. The custom applications proxy communicates with the Public API as well as pods created by the LRS

Troubleshooting

Common issues and solutions when setting up the proxy:

  1. On AWS (or another provider which uses ECR as an image provider) we need to setup an ECR repo for custom applications images. These instructions have details: https://github.com/datarobot/admin-guide/blob/5cc449f9411a1564b9f53bffb49389e03adb3bf5/installation-9p0/container-images.md?plain=1#L89-L120 If you are using a different image provider, you won't need to do this.
  2. If you are having issues with image uploads, you should verify IMAGE_BUILDER_CUSTOM_APPLICATION_REGISTRY_REPO is correct

  3. If you see logs saying failed to get a token: the status code is 401 you may need to re-hydrate your drauth secret. To do this:

  4. Delete the secret named drauth-custom-apps-websocket-proxy

  5. Edit the configmap with the secret (kubectl edit drauth-custom-apps-websocket-proxy-config)
  6. Just make some change: for example, you may want to add a label a: "b"
  7. Save the changes to the configmap
  8. Verify that when you lookup the secrets you see drauth-custom-apps-websocket-proxy as a new secret
  9. See if the custom applications proxy pod has restarted: kubectl get pods -n dr-app-charts-master-daily | grep custom-apps
  10. If the pod has not been restarted, delete it kubectl delete pod <podname>

  11. The proxy should have the latest drauth creds

  12. Logs similar to: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)"} indicate that it is required the public API to be the service URL of the public API. This command, as written should fix it for the deployment:

kubectl set env deployment/custom-apps-websocket-pr-app PUBLIC_API_URL=http://datarobot-nginx/api/v2

Even if the cluster is on a different ingress than nginx (eg openshift-default) we'll need to use this. This will also require customers to send HTTP requests from a custom app to the Public API with that service URL.

  1. Errors like: dial tcp: lookup auth-server-hydra-public.dr-auth.svc.cluster.local on 172.x.y.z:b: no such host mean that something is wrong with the hydra URL - in this specific case the URL contains an unexpected namespace (dr-auth).
  2. If there are errors sending HTTP requests from Custom applications --> Public API, you must use the URL http://datarobot-nginx/api/v2/ instead of whatever URL you have.