OpenAgent: one Go binary, port 14000, and an agent loop that runs shell commands

The installer fetches a release and opens port 14000

The front door is a port number. Pre-built binaries exist for Linux, macOS and Windows on both x86_64 and arm64, the installer downloads the newest release, and the process comes up on port 14000, where you open http://localhost:14000 in a browser. There is no application to install and no service to configure first, which is why the project describes itself as shipping as a single binary.

On macOS, Linux and WSL that is one shell pipeline:

curl -fsSL https://raw.githubusercontent.com/the-open-agent/openagent/master/scripts/install.sh | bash

On Windows it is the PowerShell equivalent, and the README is explicit that Windows runs natively, with no WSL and no Docker required:

irm https://raw.githubusercontent.com/the-open-agent/openagent/master/scripts/install.ps1 | iex

Three environment variables tune the installer: OPENAGENT_VERSION pins which release is downloaded, while INSTALL_DIR and BIN_DIR decide where the installer puts files. Left alone, the server you get is whatever the newest release tag happens to be, which is v2.95.1, published on 2026-10-05.

Source build and compose build cost different things

There are two more routes in, and each one leaves you with something different. Building from source needs Go 1.25.0 or newer for the backend, with go.mod pinning toolchain go1.25.8, plus Node.js 20+ and Yarn 1.x for the frontend. The two halves are built separately:

go build
cd web && yarn install && yarn start

The Docker route is one command:

docker-compose up

The difference is what you own afterwards. The source build gives you a Go binary and a live frontend dev server, which is what you want while changing the web UI. docker-compose up builds the STANDARD target of the Dockerfile instead, so the Node 22 frontend stage runs yarn build ahead of time and the compiled UI is copied into the runtime image, and it starts a second container for MySQL 8.0.25 that the server waits on. Both routes end at http://localhost:14000, and the install script from the previous section remains the only route that asks you no questions at all.

The compose entrypoint runs --createDatabase=true on startup

docker-compose.yml is where the deployment assumptions are written down, and two of them deserve a second look. The openagent service is built from the repository Dockerfile with target STANDARD, restarts always, publishes 14000 on the host, and replaces the image entrypoint with a shell wrapper:

entrypoint: /bin/sh -c './server --createDatabase=true'
depends_on:
  - db
environment:
  RUNNING_IN_DOCKER: "true"
  DOCKER_DB_HOST: db
volumes:
  - ./conf:/conf/

The flag creates the database on first boot, and RUNNING_IN_DOCKER tells the binary that it is containerised. The db service is mysql:8.0.25 pinned to platform linux/amd64, which matters on an Apple Silicon host where that image runs under emulation. Two defaults want changing before this reaches a shared machine: the compose file sets MYSQL_ROOT_PASSWORD to 123456, and the database port 3306 is published to the host. The conf directory is mounted rather than baked in, so the configuration the server reads is the one on your filesystem, not the copy the Dockerfile ships.

Shell execution and browser driving share one agent loop

The agent loop is where most of the platform's surface area sits, and the capability table is specific about what each piece touches. Browser-Use drives a real browser: navigate, click, fill forms, scrape, screenshot. Web Search and Fetch pull live page content into the context. Shell Execution runs commands and scripts straight from the loop. Office Automation reads and writes Word, Excel and PowerPoint files. MCP Integration accepts any MCP-compatible server over SSE, Stdio or StreamableHTTP. Transparent Tool Calls shows every invocation with its arguments and its return value, step by step.

go.mod lines up with that table: chromedp and cdproto for the browser, aymanbagabas/go-pty for the shell, ThinkInAIXYZ/go-mcp for the MCP client, carmel/gooxml for Office files, robfig/cron for the scheduler.

Stores are assigned per chat, and chunking stays undocumented

The knowledge base side has four moving parts. Document Ingestion takes PDFs, Word documents and Excel sheets and chunks, embeds and indexes them automatically. Semantic Search retrieves the most relevant passages before each LLM response, so retrieval happens per turn instead of as a step you trigger. Pluggable Embeddings covers OpenAI, Azure, Gemini, Qwen, Cohere, Jina, HuggingFace and local models. Isolated Stores organise knowledge into separate stores that you assign per chat or per application, which is how one server serves several projects without mixing corpora.

The database side is at least legible in go.mod, which pulls MySQL, Postgres and SQL Server drivers next to the MySQL 8.0.25 container the compose file starts.

Provider switching happens per conversation, not per build

The headline count is 30+ model providers, listed as OpenAI, Azure OpenAI, Anthropic Claude, Gemini, DeepSeek, Mistral, Grok, Qwen, Doubao, Moonshot, ChatGLM, Baichuan, Ernie, iFlytek, HuggingFace, Cohere, Amazon Bedrock, OpenRouter and Ollama, with more behind that list. The switching model matters more than the count: you change provider per conversation with no code changes required, so one deployment can route different requests to different vendors.

The dependencies show how each family is reached: anthropic-sdk-go for Claude, openai-go/v2 and sashabaranov/go-openai for OpenAI, aws-sdk-go-v2 with the Bedrock runtime client, cohere-go for Cohere, mistral-go for Mistral, dashscopego for Qwen, the Baidu qianfan client, and casibase/go-openrouter for OpenRouter. Usage Analytics tracks token consumption and cost per provider, model and user, with pkoukk/tiktoken-go in the build for counting. cenkalti/backoff also sits in go.mod.

The alpine image runs as uid 1000 with passwordless sudo

The runtime image says more about deployment than the feature list does. The final stage is alpine:latest, and one of its first actions is rewriting the package repositories from https to http with sed before adding sudo, curl, nodejs and ca-certificates. It then creates a user named casibase at uid 1000, gives that user NOPASSWD access to everything through a sudoers file, and drops to it:

RUN sed -i 's/https/http/' /etc/apk/repositories
ARG USER=casibase
RUN adduser -D $USER -u 1000 \
ENTRYPOINT ["/server"]
ENV RUNNING_IN_DOCKER=true

From there it copies the server binary, the data directory, conf/app.conf, the skills directory, the built web UI and pptx-worker/worker.bundle.mjs, then runs the server as the entrypoint. A separate Node 22 stage builds that PowerPoint worker from tool/pptx-worker/worker.mjs with npm ci, so Office handling depends on a JavaScript bundle inside the image.

Activity is regular rather than sporadic: v2.94.8 on 2026-10-01, then v2.95.0 and v2.95.1 on 2026-10-05, with the last push on 2026-11-02. Release plumbing sits in .goreleaser.yaml and .releaserc.json, a riscv64.Dockerfile sits beside the main one, and swagger output, an i18n directory, a README_zh.md, plus SECURITY.md, CONTRIBUTING.md and CLAUDE.md are all at the top level.

Editorial conclusion

OpenAgent fits a team that wants one self-hosted server for several model providers, a private document store and scheduled agent jobs, and it does not fit anyone who needs a hardened default configuration, because the compose file publishes MySQL with a trivial root password and the container runs sudo with no password. Before you deploy it anywhere shared, change the database credentials, decide whether the shell execution capability belongs in that environment at all, and check what your own conf directory overrides, since that mount replaces the packaged app.conf.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. the-open-agent/openagent on GitHub