https://my.orq.ai unless told otherwise. Self-hosted and on-premise deployments serve the same API paths under their own hostname, so every client must be pointed at that hostname explicitly. No client reads the base URL from the environment on its own.
Base URLs
Only the host changes between deployments. The paths stay the same: a deployment reachable at
https://orq.example.com serves the router at https://orq.example.com/v3/router and the OTLP endpoint at https://orq.example.com/v2/otel.
Set ORQ_BASE_URL alongside ORQ_API_KEY and read both from the environment, so the same code runs against the managed cloud and a self-hosted deployment without edits:
Orq SDKs
Pass the base URL asserverURL (Node.js) or server_url (Python):
The Node.js option is
serverURL, with URL in uppercase. serverUrl is not a valid option and leaves the client pointed at the managed cloud.AI Gateway
OpenAI-compatible clients take the router path as their base URL:https://my.orq.ai with the deployment hostname when configuring them.
OpenTelemetry
Exporters read the endpoint from the environment. Point it at the deployment host:$ORQ_BASE_URL/v2/otel/v1/traces. See the Observability quickstart for the full exporter setup.
Troubleshooting
Requests reach the managed cloud instead of the deployment. The base URL was not applied. In Node.js, confirm the option is spelledserverURL and not serverUrl. In Python, confirm server_url is passed to the Orq constructor rather than to the individual method call. When the option is missing or misspelled the SDKs fall back to the host published in the OpenAPI specification, https://api.orq.ai, so calls succeed against the managed cloud instead of failing outright.
On-Prem Requirements
Infrastructure requirements for deploying Orq.ai on-premise, including the DNS record and TLS certificate for the platform hostname.