rajshah4 · Oct 2, 2026 · Oct 2, 2026 · Oct 2, 2026 · Oct 4, 2026 · Oct 8, 2026
diff --git a/docs.json b/docs.json
@@ -612,6 +612,7 @@
               },
               "enterprise/integrations/slack",
               "enterprise/integrations/external-llm-gateways",
+              "enterprise/integrations/aws-bedrock-llm-gateway",
               "enterprise/integrations/observability-platforms"
             ]
           },

diff --git a/enterprise/integrations/aws-bedrock-llm-gateway.mdx b/enterprise/integrations/aws-bedrock-llm-gateway.mdx
@@ -0,0 +1,208 @@
+---
+title: AWS Bedrock LLM Gateway
+description: Connect Amazon Bedrock models through the OpenHands Enterprise LLM gateway.
+icon: cloud
+---
+
+OpenHands Enterprise can use Amazon Bedrock through its bundled LiteLLM
+gateway. Configure the gateway according to how you installed OpenHands.
+The Helm IRSA example assigns the Bedrock role to the **LiteLLM ServiceAccount**.
+Replicated uses the credential behavior described in its tab below.
+
+## Configure the Gateway
+
+<Tabs>
+<Tab title="Replicated">
+
+1. Open the [Admin Console LLM configuration](/enterprise/vm-install/admin-console-configuration#llm-configuration).
+2. Select `AWS Bedrock` and enter the AWS Region.
+3. Under `AWS Authentication Method`, choose one of the Admin Console options:
+   - `Access Key + Secret`: enter the `AWS Access Key ID` and matching
+     `AWS Secret Access Key` in their required fields.
+   - `EC2 Instance Profile`: attach an IAM role to the EC2 instance. In a
+     containerized installation, set the instance metadata service (IMDS)
+     response hop limit to at least 2 so the LiteLLM pod can reach it.
+
+   Grant the chosen IAM identity `bedrock:InvokeModel` and
+   `bedrock:InvokeModelWithResponseStream` for every model you add.
+4. In `Bedrock Model IDs`, enter **one Bedrock model ID or inference profile ID
+   per line**. Enter the IDs as AWS provides them, without the `bedrock/`
+   prefix. For example:
+
+   ```text
+   us.anthropic.claude-haiku-4-5-20251001-v1:0
+   us.anthropic.claude-sonnet-4-5-20250929-v1:0
+   ```
+
+   The Admin Console creates a separate bundled-gateway model for each line.
+   The first line becomes the installation default. Use IDs available to your
+   account and selected Region; check each inference profile with
+   `aws bedrock get-inference-profile` before adding it.
+5. Save the configuration and deploy the updated version.
+
+If you add a cross-Region inference profile, keep its full ID, including the
+`us.` prefix in these examples. Your IAM policy must permit the profile and
+its destination models. A standard model ID is Region-specific. The
+`Allow users to configure their own LLM providers (BYOK)` checkbox controls
+whether users can add personal providers; it is not required for these
+administrator-managed Bedrock models.
+
+<Note>
+In the Replicated static-key configuration, the installer also passes the AWS
+access key and secret into sandbox environments. With an EC2 instance profile,
+sandboxes may also reach IMDS unless your network controls prevent that access;
+a response hop limit of 2 does not isolate credentials to the gateway.
+Scope the IAM identity for this deployment behavior rather than assuming that
+only the LiteLLM pod can use it.
+</Note>
+
+</Tab>
+<Tab title="Helm">
+
+### Prerequisites
+
+- A working [OpenHands Enterprise Helm installation](/enterprise/k8s-install/installation).
+- A Bedrock model that supports the agent's tool use, with model access enabled
+  in your AWS account. Confirm its Region and, if required, its inference
+  profile ID in the [Bedrock model catalog](https://docs.aws.amazon.com/bedrock/latest/userguide/models.html).
+- HTTPS access from the bundled LiteLLM pod to the Bedrock Runtime endpoint.
+
+The example below uses an **EKS IAM role for service accounts (IRSA)**, so it
+does not put long-lived AWS keys in Helm values or Kubernetes Secrets. Other
+Kubernetes platforms can supply AWS credentials to the LiteLLM pod using
+their supported credential mechanism.
+
+### 1. Grant the LiteLLM Service Account Bedrock Access
+
+Create an IAM role whose trust policy allows your EKS cluster's OIDC provider
+to assume it only for the ServiceAccount
+`system:serviceaccount:openhands:openhands-litellm-bedrock`. Follow the
+[AWS IRSA setup guide](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)
+to create the OIDC provider and role. If you use a different namespace or
+ServiceAccount name, use those values in both the trust policy and Helm values.
+
+Grant the role `bedrock:InvokeModel` and
+`bedrock:InvokeModelWithResponseStream` for every model you will use. If a
+model requires a cross-Region inference profile, include the inference
+profile ARN in the source Region and every destination foundation-model ARN
+returned by `GetInferenceProfile`. For example:
+
+```bash
+aws bedrock get-inference-profile \
+  --region <source-region> \
+  --inference-profile-identifier <profile-id> \
+  --query '{profile:inferenceProfileArn,models:models[*].modelArn}'
+```
+
+Restrict the policy to those returned ARNs. AWS also requires your
+organization's service control policies to allow the profile's destination
+Regions; see [cross-Region inference permissions](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html).
+
+### 2. Add a Bedrock Route to Helm Values
+
+Merge the following into your **complete** installation `values.yaml`. Keep
+your existing `litellm-helm.proxy_config.model_list` entries: Helm replaces
+lists when applying overrides. Replace the role ARN, Region, and model ID with
+your own values.
+
+```yaml
+litellm-helm:
+  serviceAccount:
+    create: true
+    name: openhands-litellm-bedrock
+    annotations:
+      eks.amazonaws.com/role-arn: arn:aws:iam::<account-id>:role/<bedrock-role>
+  proxy_config:
+    model_list:
+      # Retain your existing model entries here.
+      - model_name: bedrock-haiku-4-5
+        litellm_params:
+          model: bedrock/us.anthropic.claude-haiku-4-5-20251001-v1:0
+          aws_region_name: us-west-2
+      - model_name: bedrock-sonnet-4-5
+        litellm_params:
+          model: bedrock/us.anthropic.claude-sonnet-4-5-20250929-v1:0
+          aws_region_name: us-west-2
+```
+
+Add one `model_list` entry per model. Each `model_name` is the alias OpenHands
+uses to select that route. In Helm values, prefix the AWS model or inference
+profile ID with `bedrock/` in `litellm_params.model`; the Admin Console field
+above takes the raw ID instead. If you change the alias that should be the
+installation default, also set `env.LITELLM_DEFAULT_MODEL` to
+`litellm_proxy/<alias>` in the same values file.
+
+### 3. Apply and Verify
+
+Use the licensed chart URL and version from your installation:
+
+```bash
+helm upgrade openhands "$OPENHANDS_CHART_URL" \
+  --namespace openhands \
+  --version "$OPENHANDS_CHART_VERSION" \
+  --values values.yaml \
+  --wait --timeout 10m
+
+kubectl -n openhands rollout status deployment/openhands-litellm
+kubectl -n openhands get serviceaccount openhands-litellm-bedrock \
+  -o jsonpath='{.metadata.annotations.eks\.amazonaws\.com/role-arn}'
+```
+
+Adjust the namespace, release name, and Deployment name if they differ in your
+installation. The annotation should contain the IAM role ARN from your values.
+
+</Tab>
+</Tabs>
+
+## Select the Model in OpenHands
+
+For a Replicated installation, select the Bedrock model configured in the
+Admin Console. For a Helm installation, create a profile in `Settings` → `LLM`
+for each gateway alias you want users to select. For the first Helm example
+above, use:
+
+| Field | Value |
+| --- | --- |
+| Profile Name | `Bedrock-Haiku-4-5` |
+| Model | `openhands/bedrock-haiku-4-5` |
+| Base URL | `http://openhands-litellm.openhands.svc.cluster.local:4000` |
+| API Key | Leave unset; use the managed gateway credential |
+
+Use your installation's actual LiteLLM Service name and namespace. The profile
+points to the **internal gateway**, not to a Bedrock endpoint.
+For the second Helm route, create another profile with Model
+`openhands/bedrock-sonnet-4-5` and the same Base URL.
+
+## Start Using the Model
+
+1. Select the Bedrock profile and start a new conversation.
+2. Ask the agent to run `pwd`.
+3. Confirm it starts a sandbox, runs the command, and replies with the output.
+
+## Troubleshooting
+
+<AccordionGroup>
+<Accordion title="Bedrock AccessDeniedException">
+Check the IAM role annotation on the LiteLLM ServiceAccount, the role trust
+policy's exact namespace and ServiceAccount subject, and the role's model
+invocation policy. For a cross-Region inference profile, include its source
+profile ARN and all destination model ARNs; check organization service control
+policies for denied Regions.
+</Accordion>
+<Accordion title="Model or inference profile not found">
+Check the exact model or profile ID and `aws_region_name`. A model available in
+one Region may require an inference profile in another.
+</Accordion>
+<Accordion title="The profile cannot reach the gateway">
+Check the internal LiteLLM Service DNS name, namespace, and profile base URL.
+Confirm the LiteLLM Deployment is ready and its logs show the Bedrock route.
+</Accordion>
+<Accordion title="The model answers a short prompt but the agent cannot work">
+Confirm the Bedrock model supports tool use and that its account quotas allow
+larger agent prompts. Test a full conversation with a sandbox command, not
+only a direct model completion.
+</Accordion>
+</AccordionGroup>
+
+For provider-specific model configuration, see
+[LiteLLM's Bedrock reference](https://docs.litellm.ai/docs/providers/bedrock).
diff --git a/enterprise/integrations/overview.mdx b/enterprise/integrations/overview.mdx
@@ -15,7 +15,7 @@
 | -------------- | ---------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
 | Purpose        | Purpose-built integrations for OpenHands Enterprise                                                                                | Extend agent access to external systems through MCP servers                             |
 | Data flow      | Bidirectional (outbound and event-driven)                                                                                          | Unidirectional (outbound only)                                                          |
 | Integrations   | Git and ticketing providers: GitHub, GitLab, Bitbucket Cloud, Bitbucket Data Center, Azure DevOps, Jira Cloud, Jira Data Center, Slack | Large MCP catalog across multiple integration categories                                |
 | Authentication | OAuth                                                                                                                              | OAuth or bearer token                                                                   |
 | Administration | Super admins enable or disable specific integrations and configure their OAuth app IDs, client IDs, and client secrets             | End users manage their own MCP connections                                              |
 | Navigation     | `Settings > Integrations`                                                                                                          | `Customize > MCP Servers`                                                               |
@@ -55,7 +55,7 @@
    Configure Bitbucket Data Center sign-in and repository webhooks.
  </Card>
  <Card title="Azure DevOps" icon="microsoft" href="/enterprise/integrations/azure-devops">
    Connect Azure Repos and Azure Boards with Microsoft Entra ID sign-in.
  </Card>
 </CardGroup>

@@ -66,10 +66,10 @@

 <CardGroup cols={2}>
  <Card title="Jira Cloud" icon="jira" href="/enterprise/integrations/jira-cloud">
    Start OpenHands from Jira Cloud issues with a mention or label.
  </Card>
  <Card title="Jira Data Center" icon="jira" href="/enterprise/integrations/jira-data-center">
    Start OpenHands from Jira Data Center issues with a mention or label.
  </Card>
 </CardGroup>

@@ -91,7 +91,7 @@

 <CardGroup cols={2}>
  <Card title="SAML SSO" icon="user-shield" href="/enterprise/integrations/saml-sso">
    Let users sign in with Okta, Microsoft Entra ID, Google Workspace, ADFS, or Authentik.
  </Card>
 </CardGroup>

@@ -102,31 +102,31 @@

 ### Integration Coverage

 - **Fetch repos**: Fetch and clone repositories (Git providers only).
 - **Resolver**: Use OpenHands in conversations, issues, and pull requests.
 - **Auth IdP**: Sign in to OpenHands Enterprise through the integration.

 | Integration                                                                                                  | Fetch repos     | Resolver                                                                                                                  | Auth IdP                       |
 | ------------------------------------------------------------------------------------------------------------ | --------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
 | [GitHub](/enterprise/integrations/github)                                                                    | ✅              | ✅                                                                                                                        | ✅ GitHub App sign-in          |
 | [GitLab](/enterprise/integrations/gitlab) (SaaS and self-managed)                                            | ✅              | ✅                                                                                                                        | ✅                             |
 | [Bitbucket Data Center](/enterprise/integrations/bitbucket-data-center)                                      | ✅              | ✅                                                                                                                        | ✅                             |
 | [Bitbucket Cloud](/openhands/usage/cloud/bitbucket-installation)                                             | ✅              | ❌                                                                                                                        | ❌                             |
 | [Azure DevOps](/enterprise/integrations/azure-devops)                                                        | ✅ Azure Repos  | Supported, but requires an [event-based automation](/enterprise/integrations/azure-devops#trigger-openhands-from-azure-devops) | ✅ Microsoft Entra ID          |
 | [Jira Cloud](/enterprise/integrations/jira-cloud)                                                            | N/A             | ✅                                                                                                                        | ❌                             |
 | [Jira Data Center](/enterprise/integrations/jira-data-center)                                                | N/A             | ✅                                                                                                                        | ❌                             |
 | [Slack](/enterprise/integrations/slack)                                                                      | N/A             | ✅                                                                                                                        | N/A                            |
 | [SAML SSO](/enterprise/integrations/saml-sso) (Okta, Entra ID, Google Workspace, ADFS, Authentik)            | N/A             | N/A                                                                                                                       | ✅ Recommended sign-in method  |

 ## MCP Server Integrations

 MCP server integrations provide additional ways for users to connect external systems to OpenHands. They support
 multiple server types, including SSE, streamable HTTP (SHTTP), and stdio, as well as authentication methods such as
 bearer tokens and OAuth.

 Examples include:

 - **OAuth-enabled**: Atlassian Rovo, GitLab, Granola
 - **Token-enabled**: Linear, Notion

 Unlike built-in integrations, MCP servers are **unidirectional**: the OpenHands agent calls the MCP server to access data,
@@ -134,13 +134,16 @@

 See [MCP Settings](/openhands/usage/settings/mcp-settings) to add and configure MCP servers.

 ## Agentic Infrastructure

 <CardGroup cols={2}>
   <Card title="External LLM Gateways" icon="network-wired" href="/enterprise/integrations/external-llm-gateways">
     Route LLM traffic through your existing LiteLLM or Bifrost gateway for routing, cost tracking, and audit.
   </Card>
+  <Card title="AWS Bedrock" icon="cloud" href="/enterprise/integrations/aws-bedrock-llm-gateway">
+    Connect Bedrock models through the bundled gateway on Replicated or Helm.
+  </Card>
   <Card title="External Observability Platforms" icon="chart-line" href="/enterprise/integrations/observability-platforms">
     Send conversation traces to your own OTLP-compatible platform, such as Langfuse, Honeycomb, or Tempo.
   </Card>
 </CardGroup>
diff --git a/enterprise/k8s-install/installation.mdx b/enterprise/k8s-install/installation.mdx
@@ -33,7 +33,7 @@
  `app.openhands.example.com` (application), `auth.openhands.example.com`
  (login), `runtime-api.openhands.example.com`, and
  `<id>-runtime.openhands.example.com` for the per-session sandboxes. Every
  hostname sits one label under the base domain, so a single **wildcard**
  record `*.openhands.example.com` pointing at your cluster's ingress covers
  all of them; see [DNS and TLS](/enterprise/k8s-install/dns-and-tls).
 - A **wildcard TLS certificate** for `*.openhands.example.com`, which you provide.
@@ -54,12 +54,12 @@
 unset OH_LICENSE_ID
 ```

 ## Step 2: Create the namespaces and secrets

 We recommend running agent sandboxes in a namespace separate from the
 application. Sandboxes run agent-authored code, so a dedicated namespace keeps
 them isolated from the application, database, and secrets. Create both
 namespaces now:

 ```bash
 kubectl create namespace openhands
@@ -67,7 +67,7 @@
 ```

 The chart references several Kubernetes secrets that you create ahead of
 installation, all in the `openhands` namespace:

 ```bash
 kubectl -n openhands create secret generic jwt-secret \
@@ -162,7 +162,7 @@
  data.
 </Warning>

 The example below uses Traefik, the chart's default ingress class; set
 `ingress.class` and the annotations to match your controller.

 ```yaml
@@ -312,7 +312,7 @@
 ```

 <Tip>
  The `preflight` and `support-bundle` CLIs are both part of
  [Troubleshoot](https://troubleshoot.sh/docs/#installation). Install them with:

  ```bash
@@ -321,7 +321,7 @@
  ```
 </Tip>

 Then confirm the application is reachable at your configured hostname and log
 in. A complete first-use check goes beyond Ready pods and preflight:

 1. Open `https://app.openhands.example.com` and sign in through your configured
@@ -361,6 +361,9 @@
   <Card title="Automations" icon="clock" href="/enterprise/k8s-install/automations">
     Run scheduled or event-triggered tasks on a Helm installation.
   </Card>
+  <Card title="AWS Bedrock" icon="cloud" href="/enterprise/integrations/aws-bedrock-llm-gateway">
+    Route models through the bundled gateway using an IAM role on EKS.
+  </Card>
   <Card title="Plugin Marketplace" icon="puzzle-piece" href="/enterprise/plugin-marketplace">
     Offer curated plugins to your users.
   </Card>

diff --git a/enterprise/vm-install/admin-console-configuration.mdx b/enterprise/vm-install/admin-console-configuration.mdx
@@ -36,14 +36,14 @@

 ### Recommended: Simple

 Use the default `Simple` mode unless your organization requires a custom hostname for each service.

 1. Leave `Hostname Configuration Mode` set to `Simple (default)`.
 2. Enter your `Base Domain`, such as `openhands.example.com`.

 Every hostname sits one subdomain under the base domain, so a single wildcard DNS record and TLS certificate for `*.openhands.example.com` cover all of them:

 | Service | Hostname |
 |---|---|
 | Admin Console | `admin.openhands.example.com:30000` |
 | OpenHands application | `app.openhands.example.com` |
@@ -54,7 +54,7 @@
 | Sandboxes | `<id>-runtime.openhands.example.com` |

 <Note>
  Installations created before the Simple layout run in `Legacy` mode, which nests some hostnames deeper (`auth.app.<base>`, `*.runtime.<base>`). Keep existing installs on Legacy; their certificates and OAuth callbacks were issued for those hostnames.
 </Note>

 <Accordion title="Customize every hostname">
@@ -62,19 +62,19 @@

  | Field | Description |
  |---|---|
  | `Application Hostname` | Hostname for the OpenHands application. |
  | `Analytics Hostname` | Hostname for the analytics service. |
  | `Authentication Hostname` | Hostname for Keycloak. |
  | `LLM Proxy Hostname` | Hostname for the bundled LiteLLM proxy. |
  | `Runtime API Hostname` | Hostname for the Runtime API. |
  | `Runtime Base Hostname` | Base hostname used to create sandbox routes. |

  You must create DNS records, issue certificates, and configure external OAuth and webhook callbacks for the complete custom hostname set.
 </Accordion>

 ### Additional CORS Origins

 `Additional Permitted CORS Origins` is optional in either hostname mode. Enter a comma-separated list of browser origins, including the scheme and host with no path or trailing slash. The OpenHands application origin is always allowed automatically.

 ## Certificate Configuration

@@ -99,7 +99,7 @@
 | `Google` | Google AI Studio API key, or Vertex AI project, location, service-account file, and model IDs |
 | `DeepSeek` | API key |
 | `Mistral AI` | API key |
 | `Azure` | Authentication method, endpoint, API version, deployment names, and either an API key or Microsoft Entra service-principal credentials |
 | `Groq` | API key |
 | `OpenRouter` | API key |
 | `AWS Bedrock` | Authentication method, AWS Region, model IDs, and optionally an access-key pair |
@@ -108,7 +108,7 @@
 ### Provider Notes
 
 - For Azure, deployment names must exist at the configured endpoint and API version.
-- For AWS Bedrock, use an EC2 instance profile where possible. Pods must be able to reach the instance metadata service, and the role needs model invocation permissions.
+- For AWS Bedrock, use an EC2 instance profile where possible. Pods must be able to reach the instance metadata service, and the role needs model invocation permissions. See the [AWS Bedrock gateway guide](/enterprise/integrations/aws-bedrock-llm-gateway) for model IDs, inference profiles, and verification.
 - For custom OpenAI-compatible endpoints, prefix model names with `openai/`.
 - Model lists accept one model per line.
 
@@ -142,11 +142,11 @@

 ### Azure DevOps Authentication

 Configure the Microsoft Entra tenant, Azure DevOps organization, client ID, and client secret. See [Azure DevOps](/enterprise/integrations/azure-devops).

 ### Jira Data Center Integration

 Configure the Jira base URL, account-linking method, and either OAuth or service-account credentials. See [Jira Data Center](/enterprise/integrations/jira-data-center).

 ### GitHub Authentication

@@ -163,7 +163,7 @@

 ### GitLab Authentication

 Provide the GitLab host and OAuth client credentials. Leave the host at `gitlab.com` for GitLab SaaS, or enter the hostname of your self-managed GitLab instance.

 ### Slack

@@ -175,7 +175,7 @@

 | Field | Description |
 |---|---|
 | `SMTP Host` | SMTP server hostname. |
 | `SMTP Port` | SMTP server port. The default is `587`. |
 | `SMTP From Email` | Sender address for OpenHands notifications. |
 | `Use SMTP SSL` | Uses implicit TLS/SMTPS. |
@@ -195,7 +195,7 @@
 - SSL mode
 - Username and password
 - Whether OpenHands should create databases automatically
 - Database names for OpenHands, Keycloak, LiteLLM, Runtime API, and Automations

 See [External PostgreSQL](/enterprise/external-postgres) for version, encoding, privilege, and database requirements.

@@ -244,7 +244,7 @@
 |---|---|
 | `HTTP_PROXY` | Proxy URL for HTTP traffic. |
 | `HTTPS_PROXY` | Proxy URL for HTTPS traffic. |
 | `NO_PROXY` | Additional comma-separated hosts that bypass the proxy. OpenHands adds internal services and configured deployment hostnames automatically. |
 | `SSL Verification` | Verifies outbound TLS certificates. Keep enabled unless a trusted proxy configuration requires otherwise. |

 Prefer adding the proxy CA under `Additional Trusted CA Certificates` instead of disabling TLS verification.
@@ -268,11 +268,11 @@

 See [Analytics](/enterprise/analytics) for the complete setup and verification flow.

 ## Automations

 `Enable Automations` deploys the Automations UI and backend.

 If you use external PostgreSQL, create and grant access to the Automations database before enabling this option.

 ## Advanced Options

@@ -290,10 +290,10 @@

 ## Installer-Managed Secrets

 Replicated generates internal PostgreSQL, Redis, JWT, Keycloak, LiteLLM, sandbox, plugin-directory, and Automations secrets during installation. These values are intentionally hidden from the configuration screen.

 <Warning>
  Do not rotate installer-managed secrets manually unless OpenHands Support provides a component-specific procedure. In particular, changing the LiteLLM salt key makes provider credentials already stored by LiteLLM undecryptable.
 </Warning>

 ## Related Guides