OpenHands is the most-starred self-hosted AI coding agent platform on GitHub, bar none. As of late July 2026 it sits at 82,338 stars, 10,545 forks, MIT license, primarily TypeScript, started on March 13, 2024, with the latest release cloud-1.47.1. What it does in one sentence: give you a self-hosted developer control center that consolidates coding agents like OpenHands, Claude Code, Codex, and Gemini into one always-on engineering team-local, Docker, VM, or cloud backend, your choice; the agent runs on whatever machine you point it at, with Slack/GitHub/Linear automation so an incoming issue auto-decomposes into tasks and a scheduled report posts to Slack. The console is called Agent Canvas, the frontend entry point of the whole system, backed by an Agent Server (a REST API that runs multiple agents) and an Automation Server. The project is currently in beta.
What Pain It Solves
Anyone who's used coding agents has hit these walls. One, agents are scattered-Claude Code runs in the terminal, Codex in the IDE, OpenHands in its own UI, and switching means swapping context, model keys, and project directories while your brain and windows jump around. Two, agents aren't always-on: close the laptop and the agent stops, long tasks can't resume, and Slack triggers or GitHub webhooks are out of the question-the so-called "AI engineering team" is really just a few disposable tools. Three, data compliance: closed-source SaaS ships your code, issues, and internal docs to someone else's server, which is a non-starter for enterprise, finance, or healthcare. Four, automation gaps: if you want an agent to auto-decompose issues on creation or run scheduled code-review reports, the SaaS gives you a fixed workflow you can't reshape or wire into your own Linear/Notion. OpenHands pulls the agent backend back onto your own infrastructure-local, Docker, VM, on-prem, private cloud all work-with a single Agent Canvas frontend doing the scheduling, so where the agent runs and where data stays is entirely your call. Automation is wired natively through the Agent Server plus Automation Server to Slack, GitHub, Linear, and Notion, with both schedule and webhook triggers supported.
One Canvas Runs OpenHands/Claude Code/Codex/Gemini
This is its biggest split from single-agent tools. Agent Canvas runs the open-source OpenHands agent out of the box, but via ACP (Agent-Client Protocol) it accepts any third-party agent: Claude Code, Codex, and Gemini all plug in, without spinning up a separate UI or managing keys per agent. In practice you use OpenHands agent for code review today, switch to Claude Code for a new feature tomorrow, and Codex for a bug fix the day after, all without losing context-switching that's gold for multi-agent comparison and capability selection. Architecturally each Agent Server runs on a single host/port and schedules multiple agents; the Agent Canvas frontend can connect to multiple Agent Servers at once, so a team shares one server for dependency upgrades and code review while you run personal agents on your laptop, flipping between them in one panel. ACP is an open protocol-the README explicitly says "any agent with ACP"-so in theory any ACP-implementing agent can plug in, not limited to the four officially named.
Four Backends, Switchable: Local, Docker, VM, Cloud
The backend layer is the core of OpenHands' self-hosting. It decouples "where the agent runs" from "which agent you use"; the agent server installs in four places: directly on your laptop (careful-the agent has full filesystem access), on a dedicated machine like a Mac Mini, on a cloud VM, or on OpenHands Cloud/Enterprise hosted infrastructure. Two direct benefits. One, data stays on-domain: sensitive projects run on local or an internal VM, and code, issues, and tokens never leave your machine. Two, "always-on" actually holds: install the agent on a cloud VM or Mac Mini, close the laptop, and it keeps running-Slack triggers and GitHub webhooks stay responsive. The README's top recommendation is "install on a server in the cloud," because that's what makes the agent 7×24 online and reliably callable by third-party services. The Agent Canvas frontend is the same regardless of backend, so the UI is consistent and switching backends doesn't drop your session. The security caveat is also spelled out in the README: installing on bare metal gives the agent full filesystem access, so for production they strongly recommend the Docker sandbox for isolation, scoping PROJECTS_PATH to the project directories you're willing to expose.
Automation: Slack/GitHub/Linear End-to-End
Running agents isn't enough; OpenHands makes "automation" a first-class system citizen. The Automation Server pairs with the Agent Server to let you define "when and by what event an agent fires": both scheduled and webhook events are supported. Slack, GitHub, Linear, and Notion are first-class in the prebuilt integrations. A typical chain is: GitHub issue created -> triggers the OpenHands agent to auto-decompose into tasks -> posts a Slack notification when done; or scheduled code review, dependency upgrades, and report generation with results landing in Notion or a Slack channel. This turns the coding agent from "I open it, it works" into "an event arrives, it works on its own"-the essential difference from IDE-bound agents like Cursor and Cline, which have no always-on server, no automation engine, and no cross-service orchestration. The official Agent Canvas screenshot showcases the automation preview UI, signaling this is a headline scenario.
Three-Minute Setup
# Option 1: npm install (fastest, but the agent runs directly on your host with full filesystem access)
# Prerequisites: Node.js 22.12.x+, uv
npm install -g @openhands/agent-canvas
agent-canvas
# Open http://localhost:8000
# Option 2: Docker sandbox (recommended, agent isolated in a container)
# Prerequisites: Docker Desktop or Docker Engine
export PROJECTS_PATH="$HOME/projects" # project dir you're willing to expose
mkdir -p "$PROJECTS_PATH" "$HOME/.openhands"
docker run -it --rm \
-p 8000:8000 \
-v "$HOME/.openhands:/home/openhands/.openhands" \
-v "${PROJECTS_PATH}:/projects" \
ghcr.io/openhands/agent-canvas:1.6.1
# Open http://localhost:8000/canvas
# Verify: once the UI is up, add a backend, fill in the LLM key,
# and run "create a hello.txt in the current dir with the word hello" to see the agent actually touch your files.You can also split it: agent-canvas --frontend-only starts just the static frontend plus ingress, --backend-only starts just the agent server plus automation backend-useful for distributed deployments. Source install goes via git clone https://github.com/OpenHands/agent-canvas.git then npm install && npm run dev.
Who It's For + Four Pitfalls
For: dev teams wanting self-hosted coding agents for daily automation (issue decomposition, dependency upgrades, report generation); enterprises with compliance requirements where data must stay on the internal network; AI agent experimenters comparing OpenHands/Claude Code/Codex/Gemini capabilities in one panel; small teams wanting a 7×24 always-on agent that responds to Slack/GitHub webhooks.
Four pitfalls. One, bare-metal install gives the agent full filesystem access-the README flags this with a WARNING, so don't npm install -g it in production for convenience; use the Docker sandbox and scope PROJECTS_PATH down. Two, Node version: must be 22.12.x or higher; older Node won't run it, so check node -v first. Three, the mental model for multi-backend switching: Agent Canvas can connect to multiple Agent Servers, but each server has its own model keys, project directories, and isolation boundaries-switching backends isn't just switching models, it's switching a whole environment, so keep that straight. Four, it's still beta: the README top explicitly says status-beta, the npm package is @openhands/agent-canvas, and the Docker image version in the README is 1.6.1-the API and config options may still shift, so watch the changelog before production. Also, Cloud and Enterprise are commercial products, not the same thing as the open-source MIT agent-canvas-don't conflate them.
vs. the Competition
Against Devin: Devin is closed-source SaaS, so your code, tasks, and internal data all ship to someone else's server with fixed automation workflows; OpenHands is MIT open-source self-hosted, so where the backend runs, where data stays, and how automations are orchestrated are all your call-a fundamental gap on compliance and control. Against IDE-bound agents like Cursor and Cline: they're "I open the IDE, it works" tools with no always-on server, no webhook triggers, and no Slack/GitHub/Linear orchestration; OpenHands is a control center plus automation engine, positioned as an "always-on engineering team" rather than an "editor plugin," and the agents it accepts span the OpenHands/Claude Code/Codex/Gemini lineup, not just one. Against plain OpenHands agent, Agent Canvas upgrades it from "single agent" to "multi-agent orchestration plus automation platform," adding the ACP protocol layer so any third-party agent can plug in. In one line: for writing code inside the IDE use Cursor/Cline; for Devin-style automation with self-hosting and control, pick OpenHands.
References
- OpenHands GitHub repo (82,338 stars, MIT, TypeScript): https://github.com/All-Hands-AI/OpenHands
- Agent Canvas official docs (backend switching / self-hosting): https://docs.openhands.dev/openhands/usage/agent-canvas/backends
- Prebuilt automations (Slack/GitHub/Linear/Notion integrations): https://docs.openhands.dev/openhands/usage/agent-canvas/prebuilt-automations
- ACP-compatible agent onboarding: https://docs.openhands.dev/openhands/usage/agent-canvas/acp-agents
- npm package @openhands/agent-canvas: https://www.npmjs.com/package/@openhands/agent-canvas
- Community Slack channel: https://go.openhands.dev/slack