4bd3baccde ci: adopt release-please via shared release-actions (#1496)
* ci: adopt release-please via shared release-actions

Standardize agent-canvas releases on the org-wide release-please
automation (OpenHands/release-actions), matching typescript-client and
OpenHands/OpenHands.

Adds the three caller workflows:
- release.yml      release-please on push to main / release/**
- pr.yml           Conventional-Commit title lint + type: labels
- release-ready.yml draft release PR -> "Ready for review" gate
                   (Slack alert to #proj-agent-canvas + optional tests)

Adds the release-please state files: release-please-config.json
(node, draft PRs, extra-files), .release-please-manifest.json,
.github/release.yml (changelog categories), version.txt. Manifest is
seeded at 1.0.0 (the current GA release, v1.0.0 shipped 2026-06-15).

extra-files keeps the non-package.json version pins in lockstep:
config/defaults.json ($.versions.agentCanvas) and the README docker
example. The node release-type already bumps package.json and
package-lock.json.

Corrects stale on-main version refs (package.json rc.6,
config/defaults.json + README rc.11) to the real released 1.0.0, so all
pins share a single source of truth.

Removes create-release.yml: release-please now owns tag + GitHub Release
creation. npm-publish.yml and docker.yml are unchanged - they trigger on
the v* tags release-please still produces (pushed with the release App
token so tag-triggered workflows fire).

Co-authored-by: smolpaws <engel@enyst.org>

* fix: sync README.windows.md docker tag + track it in release-please

The docs-version-sync test also checks README.windows.md, which still
pinned 1.0.0-rc.11. Update both its docker image refs to the released
1.0.0 and add it to release-please extra-files (with the
x-release-please-version annotation) so future bumps keep it in lockstep
alongside README.md and config/defaults.json.

Co-authored-by: smolpaws <engel@enyst.org>

* ci: pin v-prefix tagging and first-release start point

Two robustness fixes after confirming agent-canvas's release conventions:

- include-v-in-tag: true (explicit). agent-canvas tags are vX.Y.Z
  (v1.0.0, v1.0.0-rc.12), and npm-publish.yml + docker.yml trigger on
  push tags 'v*'. release-please's node default already adds the v, but
  pin it explicitly so a default change can't silently drop the prefix
  and break tag-triggered publishing. (Matches typescript-client, which
  also ships v-prefixed tags; differs from OpenHands/OpenHands, which
  sets include-v-in-tag:false for its no-v scheme.)

- last-release-sha pinned to the v1.0.0 release commit
  (7b9c17e). v1.0.0 is a real, published release (2026-06-15; npm
  latest). This tells release-please the first managed release starts
  from there, so its first run scans only post-1.0.0 commits instead of
  walking the whole history.

Co-authored-by: smolpaws <engel@enyst.org>

* ci: drop orphaned version.txt

Per AI review: version.txt would never be updated and nothing consumes
it. The README's "four state files" guidance assumes the `simple`
release-type (which release-actions itself uses, where version.txt is
the canonical version source). agent-canvas uses `release-type: node`,
where package.json is the source of truth — so version.txt is redundant
and not auto-bumped. The other node adopters (typescript-client,
OpenHands/OpenHands) ship no version.txt either. Remove it rather than
keep a file that silently goes stale.

Co-authored-by: smolpaws <engel@enyst.org>

* docs: document the release-please flow

---------

Co-authored-by: smolpaws <engel@enyst.org>
Co-authored-by: openhands <openhands@all-hands.dev>
Co-authored-by: hieptl <hieptl.developer@gmail.com>
2026-07-09 12:22:29 +07:00
2026-04-24 17:33:22 -04:00

OpenHands logo

Agent Canvas

The self-hosted developer control center for coding agents and automations.

Run OpenHands, Claude Code, Codex, Gemini, or any ACP-compatible agent across local, remote, and cloud backends.

Project status beta CI status npm version Documentation Join us on Slack

Agent Canvas automation preview


OpenHands Agent Canvas turns your coding agents into a self-hosted, always-on engineering team. It's a developer control center for starting conversations and automating everyday tasks — like generating reports that publish to Slack or automatically decomposing GitHub issues into tasks.

It runs locally on your machine by default, but can connect to multiple “agent backends”, e.g. running agents in Docker containers, on VMs, or within your company infrastructure. You can optionally choose to run agents on OpenHands Cloud or OpenHands Enterprise infrastructure.

Agent Canvas runs the open source OpenHands agent out-of-the-box, but can use any third-party agent like Claude Code and Codex.

Self-host your way Run agents locally, in Docker, on VMs, or anywhere you can run an agent server backend
Switch between different backends Switch between local, remote, and cloud agents without losing focus
Create automations Create automations and workflows that integrate with Slack, GitHub, Linear, and more. Run on a schedule or in response to webhook events
Integrate with the tools you use Connect your automations with third-party services like Slack, GitHub, Notion, and more to automate workflows
Bring your own model Use with any LLM
Use with any agent Use with OpenHands, Claude Code, Codex, Gemini, or any agent with Agent-Client Protocol (ACP).

If you have questions or feedback, please open a GitHub issue or join the #proj-agent-canvas channel in Slack.

Quickstart

You can install OpenHands to run agents on any machine: on your laptop, on a dedicated computer like a Mac Mini, or on a server in the cloud.

The most powerful way to run OpenHands is on a server in the cloud. This allows your agents to continue running even when your laptop is shut, and makes it easier to trigger your agents through third-party services like Slack, GitHub, and Datadog. See SELF_HOSTING.md for details, especially with respect to security hardening.

Notably, you can run the backend in multiple different environments, and switch between them from the same Agent Canvas frontend. E.g. you can share an Agent Server with your team for agents doing code review and dependency updates, then have your personal agents running on your laptop.

Option 1: Without a Sandbox

Warning

This runs the agent-server directly on the machine you're installing on — the agent will have full access to your filesystem!

Prerequisites: Node.js 22.12.x or later, uv

npm install -g @openhands/agent-canvas
agent-canvas

The agent-canvas command starts the full local stack by default. You can also split it when you want to run pieces separately:

agent-canvas --frontend-only  # static frontend + ingress only
agent-canvas --backend-only   # agent server + automation backend + ingress only

Option 2: With a Docker Sandbox

Prerequisites:

  • Docker: Docker Desktop on macOS/Windows, or Docker Engine/Docker Desktop on Linux.
  • A host directory for PROJECTS_PATH containing the project folders you want the agent to access. Create it before starting the container.

macOS / Linux:

export PROJECTS_PATH="$HOME/projects"  # directory containing your project folders
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.1.0 # x-release-please-version

Windows (PowerShell / Windows Terminal): See README.windows.md for the equivalent commands.

The agent will be able to access any project under PROJECTS_PATH.

Option 3: From Source

Warning

This runs the agent-server directly on the machine you're installing on — the agent will have full access to your filesystem!

Prerequisites: Node.js 22.12.x or later, npm, uv (for running the agent server via uvx)

git clone https://github.com/OpenHands/agent-canvas.git
cd agent-canvas
npm install
npm run dev

Access the UI at http://localhost:8000. You can add additional backends directly from the UI.

Architecture

Agent Canvas is powered by the OpenHands Agent Server, a REST API for running multiple agents on a single machine. Each Agent Server runs on a single host/port; the Agent Canvas can connect to multiple Agent Servers and easily flip between them.

You can run an Agent Server anywhere:

  • Directly on your laptop (be careful!)
  • On a dedicated machine like a Mac Mini
  • On a virtual machine in the cloud
  • Inside OpenHands Cloud (our commercial offering)

The Agent Server is often paired with an Automation Server, which lets you set up agents that run on a schedule or in response to events.

image

More documentation

S
Languages
TypeScript 93.7%
JavaScript 4.7%
Python 0.9%
Shell 0.3%
CSS 0.2%
Other 0.1%