GoClaw: a multi-tenant AI agent gateway in Go, and what its licensing actually means

The problem GoClaw targets: many users, one agent deployment

Most self-hosted agent frameworks assume a single operator. One config file, one set of API keys, one conversation history. The moment a second person needs an agent, you are either running a second instance or sharing credentials, and neither is pleasant.

GoClaw's answer is multi-tenancy at the database layer. The README describes per-user workspaces, per-user context files, isolated sessions and RBAC, all on PostgreSQL. API keys are stored encrypted with AES-256-GCM rather than sitting in a shared config file. That is the whole pitch: the same binary serves several tenants and keeps their context apart.

The audience follows from that. Platform teams inside a company that want to hand out agents to several departments. Agencies running agents for more than one client. Anyone who has already tried to bolt tenancy onto a single-user agent runtime and found the seams. If you are one person running one agent on a laptop, this is more infrastructure than the job needs, and the README itself points that person at the Lite desktop build instead.

Inside the 8-stage pipeline and the three-tier memory

The request path is described as an eight-stage pipeline: context, history, prompt, think, act, observe, memory, summarize. The README calls the stages pluggable and says execution is always-on, meaning the stages run in order for every turn rather than being optional hooks a plugin author has to register.

Prompt construction is split into four modes (Full, Task, Minimal, None) with section gating and a cache boundary. The cache boundary matters because Anthropic's provider path is implemented as native HTTP with SSE and prompt caching; if the prompt prefix shifts between turns, that cache stops paying off. Mode resolution happens per session, so a cheap background task and an interactive chat can use different prompt shapes against the same agent.

Memory is layered in three tiers: working memory for the live conversation, episodic memory for session summaries, and semantic memory in a knowledge graph, loaded progressively as L0, L1 and L2. On the server build the semantic tier uses pgvector for hybrid search alongside full-text search. The desktop Lite build has no vector tier and falls back to SQLite FTS5 text search, which the README lists as a difference rather than a footnote. If semantic recall is the reason you want this, the desktop build is not the same product.

Orchestration sits above the pipeline. Agents share task boards, delegate to each other synchronously or asynchronously, and run in one of three orchestration modes: auto, explicit or manual. The README does not explain how the auto mode picks a delegate, which is the kind of gap you notice only after agents start handing work to each other in ways you did not plan.

Installing GoClaw with Docker Compose and reaching the dashboard

The README's Quick Start section points at the documentation site at docs.goclaw.sh, and the compose file carries its own short instructions. The base compose file is a shared service definition, so you layer it with the Postgres file rather than running it alone. The comment in docker-compose.yml gives the command and the resulting URL.

docker compose -f docker-compose.yml -f docker-compose.postgres.yml up -d
# Dashboard: http://localhost:18790

Before that, copy the environment template and generate the two secrets it expects. The .env.example file says GOCLAW_GATEWAY_TOKEN and GOCLAW_ENCRYPTION_KEY are auto-generated by prepare-env.sh, and that LLM provider keys are configured later in the web dashboard setup wizard rather than in the environment file.

cp .env.example .env
./prepare-env.sh

The compose file publishes the service on port 18790 by default, overridable through GOCLAW_PORT, and serves the embedded web UI on that same port. If something already occupies 5432 on your machine, .env.example notes that POSTGRES_PORT can be moved, for example to 5433, and that host-side tools should then use a DSN pointing at 127.0.0.1 with that port. A local loopback-only setup can skip authentication with GOCLAW_ALLOW_INSECURE_NO_AUTH=1, which the file explicitly frames as a development option.

For a desktop install instead of a server, the README gives a one-line installer per platform:

curl -fsSL https://raw.githubusercontent.com/nextlevelbuilder/goclaw/main/scripts/install-lite.sh | bash

On Windows the equivalent is a PowerShell one-liner using install-lite.ps1. The desktop build bundles SQLite and needs no Docker and no PostgreSQL, which is the fastest way to see whether the agent behaviour suits you before you commit to a database.

Where GoClaw gets in your way

The release line is the first thing to look at. The three most recent releases are v3.15.0-beta.208, v3.15.0-beta.207 and v3.15.0-beta.206, published within about two days of each other. A beta counter in the low two hundreds is a signal about how the maintainers ship, not a defect in itself, but it does mean pinning a version and reading the changelog is part of running this. The default branch is dev, not main, which reinforces the same point.

The licence is the second constraint, and a sharper one. The repository's LICENSE file is reported by GitHub as NOASSERTION, while the README badge states CC BY-NC 4.0. A non-commercial clause is a real boundary for a product whose stated audience is teams deploying agents at scale, since many of those teams are commercial. Read the actual licence text before you build a business on it; the badge and the repository metadata do not agree, and only the file settles it.

Third, the operational surface is wide. PostgreSQL is required for the server build, and the repository ships separate compose files for Redis, browser automation, Claude CLI, Tailscale, Cloudflare tunnels, OpenTelemetry, sandboxing and an upgrade path. Each of those is a decision, and none of them is documented in the README beyond its filename.

Finally, the README does not document rollback or downgrade. There is a docker-compose.upgrade.yml and a migrations directory, but nothing in the repository's own documentation describes what happens if a migration is applied and you need to go back. Treat that as unknown until you have read the migrations yourself.

GoClaw versus OpenClaw: the same idea with different plumbing

GoClaw describes itself as OpenClaw rebuilt in Go. The comparison that matters is not features but runtime shape. OpenClaw's ecosystem is associated with a Node.js runtime; GoClaw compiles to a roughly 25 MB static Go binary with no Node.js runtime and, per the README, sub-second startup on a small VPS. That difference shows up in deployment: a single artifact you can copy, versus a runtime you have to keep patched alongside your application.

The second difference is tenancy. GoClaw puts PostgreSQL, per-user workspaces and RBAC at the centre of the design, with encrypted API keys per tenant. If your requirement is one agent talking to you in a chat window, that architecture is overhead you will pay for in database operations and migration management. If your requirement is five teams sharing one deployment, it is the part you would otherwise build yourself.

The third difference is the desktop build. GoClaw ships a separate Lite edition as a native Wails and React application with a 5-agent ceiling and a single team of 5 members, versus unlimited agents and teams on the server. That is a deliberate feature gate rather than a technical one, and it is a clean way to evaluate the agent behaviour without adopting the server stack at all.

Maintenance, upgrades and what the licence implies

The repository is not archived. The last push was on 2026-09-09, and the most recent release, v3.15.0-beta.208, was published the same day. That is a fast-moving project rather than a dormant one, and the beta version counter suggests the maintainers are comfortable shipping frequently.

Upgrade cost is mostly database-shaped. The presence of a migrations directory and a dedicated docker-compose.upgrade.yml implies schema changes ship with releases, and a beta line with hundreds of numbered builds implies you should read the changelog before each bump rather than pulling latest on a schedule. The README does not describe a rollback procedure, so the practical safeguard is a database backup before you upgrade, taken with whatever tool you already trust for PostgreSQL.

On licensing: the README badge says CC BY-NC 4.0, which is a non-commercial licence, while the repository metadata reports NOASSERTION. CC licences are written for content, not for software, and they say nothing useful about patent grants or warranty, which is why their use on a codebase tends to attract questions. Read the LICENSE file in the repository and get your own advice if the answer affects revenue. Nothing here is legal advice, and the discrepancy between the badge and the repository metadata is exactly the kind of thing you want resolved before a procurement review, not after.

Editorial conclusion

Adopt GoClaw if you need several users or teams sharing one agent deployment and you are willing to run PostgreSQL and track a beta release line. Do not adopt it if you need a stable tagged version, if you are a commercial product that cannot live with a non-commercial licence, or if a single-user local agent is all you want, in which case the Lite desktop build is the honest fit. Before committing, verify three things yourself: the exact licence text in the LICENSE file, whether the dev branch or a tagged release is what you intend to deploy, and whether your provider keys survive the AES-256-GCM encryption path in a restore from backup.

Frequently asked questions

Official sources

1. Issues
2. nextlevelbuilder/goclaw on GitHub
3. Project website
4. README
5. Releases