docs: consolidate first-time-setup into overview carousel

docs.json

@@ -40,16 +40,41 @@
             ]
           },
           {
-            "group": "Onboarding OpenHands",
+            "group": "Onboarding Agent Canvas",
             "pages": [
-              "openhands/usage/customization/repository",
-              "openhands/usage/customization/hooks"
+              "openhands/usage/agent-canvas/overview",
+              "openhands/usage/agent-canvas/setup",
+              {
+                "group": "Setup a Pre-built Automation",
+                "pages": [
+                  "openhands/usage/agent-canvas/prebuilt-automations",
+                  "openhands/usage/agent-canvas/prebuilt/github-pr-review",
+                  "openhands/usage/agent-canvas/prebuilt/github-repo-monitor",
+                  "openhands/usage/agent-canvas/prebuilt/slack-channel-monitor"
+                ]
+              },
+              {
+                "group": "Connect and Manage Backends",
+                "pages": [
+                  "openhands/usage/agent-canvas/backends",
+                  "openhands/usage/agent-canvas/backend-setup/local",
+                  "openhands/usage/agent-canvas/backend-setup/vm",
+                  "openhands/usage/agent-canvas/backend-setup/docker",
+                  "openhands/usage/agent-canvas/backend-setup/cloud"
+                ]
+              },
+              "openhands/usage/agent-canvas/customize-and-settings",
+              "openhands/usage/agent-canvas/acp-agents",
+              "openhands/usage/agent-canvas/self-hosting",
+              "openhands/usage/agent-canvas/development",
+              "openhands/usage/agent-canvas/troubleshooting"
             ]
           },
           {
             "group": "Product Guides",
             "pages": [
               "openhands/usage/key-features",
+              "openhands/usage/customization/hooks",
               "overview/model-context-protocol",
               {
                 "group": "Skills",
@@ -74,6 +99,7 @@
                   "openhands/usage/automations/managing-automations"
                 ]
               },
+              "openhands/usage/customization/repository",
               {
                 "group": "Settings",
                 "pages": [

openhands/usage/agent-canvas/acp-agents.mdx

@@ -0,0 +1,94 @@
+---
+title: ACP Agents
+description: Drive Agent Canvas conversations with an external coding agent — Claude Code, Codex, or Gemini CLI — over the Agent Client Protocol.
+---
+
+Agent Canvas can drive your conversations with the built-in **OpenHands** agent or with an external **ACP agent** — Claude Code, Codex, or Gemini CLI. This guide explains what ACP agents are, how to onboard one, and how to switch agents or models later.
+
+## What is an ACP agent?
+
+The [Agent Client Protocol (ACP)](https://agentclientprotocol.com/protocol/overview) is a standard for talking to coding agents over JSON-RPC on stdio. Instead of Agent Canvas calling an LLM directly, the Agent Server spawns the agent's own CLI as a subprocess and relays each turn to it. The external agent manages its own LLM, tools, and execution; Agent Canvas sends messages and renders what comes back.
+
+```mermaid
+flowchart LR
+    canvas["Agent Canvas<br/>(this UI)"]
+    server["Agent Server"]
+    acp["ACP subprocess<br/>(e.g. claude-agent-acp)"]
+    llm["LLM provider<br/>(Anthropic / OpenAI / Google)"]
+    canvas -- "PATCH /api/settings<br/>(agent_kind, acp_*)" --> server
+    canvas -- "conversation turns" --> server
+    server -- "spawn + JSON-RPC over stdio" --> acp
+    acp -- "API calls" --> llm
+```
+
+The Agent Server owns the subprocess and the credentials; Agent Canvas only records *which* agent to run and surfaces a form for the secrets it needs. The agent choice is stored per backend, so switching backends can switch agents.
+
+## Supported providers
+
+| Provider | Default command |
+|---|---|
+| **Claude Code** | `npx -y @agentclientprotocol/claude-agent-acp` |
+| **Codex** | `npx -y @zed-industries/codex-acp` |
+| **Gemini CLI** | `npx -y @google/gemini-cli --acp` |
+
+The provider list is sourced from the OpenHands SDK registry (`openhands.sdk.settings.acp_providers`, mirrored into `@openhands/typescript-client`) and enriched with Canvas UI metadata. Adding or changing a provider happens upstream in the SDK.
+
+## Authentication
+
+<Info>
+  ACP agents authenticate **two ways: a subscription login, or an API key** — and the onboarding fields are optional. If you're already signed in to the provider's CLI on the machine the agent runs on, it reuses that login automatically, so locally you often don't need a key at all. **The login takes priority over an API key:** while you're signed in, a key set in the environment isn't used — so the onboarding key fields do nothing and can be left blank.
+</Info>
+
+A "subscription login" is the credential the provider's own CLI stores when you sign in once — a file in your home directory, or, for Claude Code on macOS, the system **Keychain**. When the Agent Server runs **on that same machine** (a local or self-hosted backend), the provider CLI finds that login automatically — no API key required. On a clean cloud sandbox there's no stored login, so an API key is needed instead.
+
+| Provider | Subscription login (auto-detected) | API key |
+|---|---|---|
+| **Claude Code** | A Claude Code login (Pro/Max), from Claude Code's own credential store: the **macOS Keychain**, or `~/.claude/.credentials.json` on Linux | `ANTHROPIC_API_KEY` |
+| **Codex** | A ChatGPT login (`codex login`) cached at `~/.codex/auth.json` | `OPENAI_API_KEY` |
+| **Gemini CLI** | Your Google login (`gemini`/`gemini --acp`) cached at `~/.gemini/oauth_creds.json` | `GEMINI_API_KEY` |
+
+All three collect an *optional* API key (plus base URL) in onboarding. As noted above, a subscription / OAuth login takes priority over an API key — when the provider's CLI is signed in, a key set in the environment is not used:
+
+- **Codex** — `codex login status` keeps reporting the ChatGPT login even with `OPENAI_API_KEY` set.
+- **Gemini CLI** — uses the OAuth auth type chosen at `gemini` login; `GEMINI_API_KEY` is only consulted if you switch the auth type. The free Google login is the common no-key path locally — sign in once and it just works.
+- **Claude Code** — with both present, `claude auth status` reports it is authenticated via the subscription (`claude.ai`), not the key. The login is auto-detected from the macOS Keychain (or `~/.claude/.credentials.json` on Linux); `CLAUDE_CONFIG_DIR` is **not** required for it — it only relocates Claude Code's config directory (settings/history, not the token) and signals the SDK to strip a conflicting `ANTHROPIC_API_KEY` / `ANTHROPIC_BASE_URL`.
+
+The one exception is the **base URL** (`*_BASE_URL`): a custom value points the CLI at a different endpoint (a proxy or gateway) and *does* take effect even under a login — for Gemini it rides the ACP `gateway` param. It's an advanced override, not needed for normal use.
+
+## Onboarding an ACP agent
+
+First-time users get a four-step onboarding modal. To onboard an ACP agent:
+
+1. **Choose agent** — pick Claude Code, Codex, or Gemini CLI instead of OpenHands. The choice is saved immediately to your backend's settings.
+2. **Check backend** — confirms Agent Canvas can reach the Agent Server.
+3. **Set up credentials** — enter the provider's API key (and, optionally, a custom base URL for a proxy or gateway). All three providers collect these here, and every field is optional.
+4. **Say hello** — creates your first conversation and closes the modal.
+
+<Note>
+  Every credential field is optional and the step is skippable. Leave a field blank to reuse a key already set on the backend, or to authenticate the agent through a subscription / OAuth login instead.
+</Note>
+
+### How credentials reach the agent
+
+Each credential you enter is saved as a **global secret** whose name is exactly the environment variable the Agent Server exports into the ACP subprocess (e.g. `ANTHROPIC_API_KEY`). Saving in onboarding is identical to adding the secret under **Settings → Secrets**, where you can edit or remove it anytime. Keeping the secret name equal to the env var is what makes a saved key actually reach the provider CLI.
+
+## Switching agent or model later
+
+Open **Settings → Agent** at any time:
+
+- **Agent** — switch between **OpenHands** and **ACP**.
+- **Preset** — pick a built-in provider (Claude Code, Codex, Gemini CLI) or **Custom** to point at any other ACP server.
+- **Command** — the command line used to spawn the subprocess. Selecting a preset fills this in; editing it to match another preset re-detects that provider. API keys are *not* entered here — they live in the Secrets panel.
+- **Model** — choose a suggested model for the provider or enter a custom model override. Built-in providers save a concrete model rather than leaving it blank.
+
+Saving writes an `agent_settings_diff` (`agent_kind`, `acp_server`, `acp_command`, `acp_model`) to `PATCH /api/settings`. A running conversation keeps the agent it started with; the new choice applies to conversations you start afterward.
+
+## Custom ACP servers
+
+Any stdio ACP server works: choose **Custom** in Settings → Agent and enter its launch command. Custom servers have no curated model list, so enter the model ID the server expects (if any) as a custom model. Pass credentials by adding the env vars the server reads as global secrets under **Settings → Secrets**.
+
+## Related Guides
+
+- [Customize and Settings](/openhands/usage/agent-canvas/customize-and-settings)
+- [LLM Profiles and Model Configuration](/openhands/usage/agent-canvas/llm-profiles)
+- [Connect and Manage Backends](/openhands/usage/agent-canvas/backends)

openhands/usage/agent-canvas/backend-setup/cloud.mdx

@@ -0,0 +1,6 @@
+---
+title: Setup an OpenHands Cloud Backend
+description: Connect Agent Canvas to an OpenHands Cloud backend.
+---
+
+Coming soon.

openhands/usage/agent-canvas/backend-setup/docker.mdx

@@ -0,0 +1,155 @@
+---
+title: Setup a Docker Backend
+description: Build a custom OpenHands Agent Server image and connect Agent Canvas to it.
+---
+
+This guide walks through building a **custom Agent Server image** that layers extra tooling (for example, the JDK) on top of the official base image, running it locally with Docker, and registering it as a backend in Agent Canvas.
+
+Use this approach when the default backend's toolchain is missing something your agent needs, such as a specific language runtime, build tool, or CLI.
+
+## Prerequisites
+
+- Docker installed and running
+- An LLM API key (Anthropic, OpenAI, etc.)
+- Agent Canvas installed and running locally — see [Setup](/openhands/usage/agent-canvas/setup)
+
+## 1. Build a Custom Image
+
+The OpenHands Agent Server publishes a base image at `ghcr.io/openhands/agent-server`. Extend it with a small `Dockerfile` that installs whatever your agent needs.
+
+The example below adds the JDK and a few common utilities. Save it as `Dockerfile`:
+
+```dockerfile icon="docker"
+FROM ghcr.io/openhands/agent-server:1-python
+
+USER root
+
+# Install Java (JDK) and common build/diagnostic utilities.
+RUN apt-get update \
+ && apt-get install -y --no-install-recommends \
+      default-jdk \
+      maven \
+      unzip \
+      vim \
+      less \
+ && rm -rf /var/lib/apt/lists/*
+
+# Switch back to the unprivileged user that the base image runs as.
+USER openhands
+```
+
+<Note>
+  The base image already ships with Python, Node.js, `git`, `jq`, `tmux`, build tools, and a VS Code Web + VNC stack. Only add what you actually need on top.
+</Note>
+
+<Tip>
+  For fully reproducible builds, pin to a more specific tag like `1.24.0-python` instead of `1-python`.
+</Tip>
+
+Build the image with a tag you can reference later:
+
+```bash
+docker build -t agent-server-java:latest .
+```
+
+<Tip>
+  For ARM hosts (Apple Silicon, Graviton), prefer the matching base tag (for example `latest-python` already supports multi-arch). If you need to force a platform, pass `--platform linux/amd64` to `docker build`.
+</Tip>
+
+## 2. Run the Custom Image
+
+Start the image, expose the agent server's HTTP port, and protect it with a session API key. The agent server reads `SESSION_API_KEY` from the environment and requires the same value on the `X-Session-API-Key` header for every request.
+
+Use the same name for the container as you'll use for the Agent Canvas backend — it makes it easy to tell which container backs which backend later.
+
+```bash
+# Pick any sufficiently random value; you'll paste it into Agent Canvas later.
+export SESSION_API_KEY="$(openssl rand -hex 32)"
+
+docker run -d \
+  --name agent-server-java \
+  -p 8001:8000 \
+  -e SESSION_API_KEY="$SESSION_API_KEY" \
+  agent-server-java:latest
+```
+
+Verify the server is reachable:
+
+```bash
+curl -H "X-Session-API-Key: $SESSION_API_KEY" http://localhost:8001/health
+```
+
+<Warning>
+  The agent server can execute arbitrary shell commands inside the container. Treat `SESSION_API_KEY` like a production credential and **do not expose port 8001 to the public internet** without a TLS-terminating reverse proxy in front of it.
+</Warning>
+
+To follow logs or stop the container:
+
+```bash
+docker logs -f agent-server-java
+docker stop agent-server-java
+```
+
+## 3. Add the Backend in Agent Canvas
+
+With the container running, point Agent Canvas at it:
+
+1. Open Agent Canvas.
+2. Click the backend switcher in the top bar and choose **Manage Backends**.
+3. Click **Add Backend** and fill in:
+   - **Name** — `agent-server-java` (matching the container name)
+   - **Host / Base URL** — `http://localhost:8001`
+   - **API Key** — the `SESSION_API_KEY` value from step 2
+   - **Type** — `Local`
+4. Save the backend and select it as the **active backend**.
+
+Agent Canvas will run a health check against the URL. Once it passes, the backend is ready to handle conversations using the tools you baked into the image.
+
+<Note>
+  See [Connect and Manage Backends](/openhands/usage/agent-canvas/backends) for what changes when you switch the active backend (settings, LLM availability, MCP servers, automations).
+</Note>
+
+## Running Multiple Custom Backends
+
+You can build as many custom images as you need and run each one as its own backend in Agent Canvas. A common pattern is one image per language or repo toolchain — for example a `agent-server-java` for JVM work, a `agent-server-rust` for Cargo projects, and a `agent-server-data` image with the Python data stack pre-installed.
+
+Give each container its own name, its own host port, and its own `SESSION_API_KEY`, then add a matching backend entry in Agent Canvas for each one:
+
+```bash
+# JVM toolchain on port 8001
+docker run -d --name agent-server-java \
+  -p 8001:8000 -e SESSION_API_KEY="$JAVA_KEY" \
+  agent-server-java:latest
+
+# Rust toolchain on port 8002
+docker run -d --name agent-server-rust \
+  -p 8002:8000 -e SESSION_API_KEY="$RUST_KEY" \
+  agent-server-rust:latest
+
+# Python data stack on port 8003
+docker run -d --name agent-server-data \
+  -p 8003:8000 -e SESSION_API_KEY="$DATA_KEY" \
+  agent-server-data:latest
+```
+
+In **Manage Backends**, add one entry per container using the matching name, URL, and API key. You can then switch between them from the backend selector depending on what kind of task you're working on.
+
+## Updating the Image
+
+When you want to add more tooling or pick up a newer agent server release:
+
+```bash
+docker pull ghcr.io/openhands/agent-server:1-python
+docker build -t agent-server-java:latest .
+docker stop agent-server-java && docker rm agent-server-java
+# then re-run the `docker run` from step 2
+```
+
+The existing backend entry in Agent Canvas keeps working as long as the host, port, and `SESSION_API_KEY` stay the same.
+
+## Related Guides
+
+- [Connect and Manage Backends](/openhands/usage/agent-canvas/backends)
+- [Setup a Local Backend](/openhands/usage/agent-canvas/backend-setup/local)
+- [Setup a VM Backend](/openhands/usage/agent-canvas/backend-setup/vm)
+- [Agent Server Overview](/sdk/guides/agent-server/overview)

openhands/usage/agent-canvas/backend-setup/local.mdx

@@ -0,0 +1,6 @@
+---
+title: Setup a Local Backend
+description: Run an OpenHands agent server locally and connect Agent Canvas to it.
+---
+
+Coming soon.

openhands/usage/agent-canvas/backend-setup/vm.mdx

@@ -0,0 +1,6 @@
+---
+title: Setup a VM Backend
+description: Run an OpenHands agent server on a VM and connect Agent Canvas to it.
+---
+
+Coming soon.