Aurogen: compose publishes port 80, the README says 8000, and the build is four days old

Public on 2026-03-10, last pushed 2026-03-21

The project's own news list is four entries long and they span four days. Aurogen went live on 2026-03-10, one-click installer packages followed on 2026-03-11, the documentation site on 2026-03-12, and native Agent Group mode on 2026-03-14. The releases match that tempo: v0.1.2 and v0.2.0 both published on 2026-03-13, about seven and a half hours apart, followed by v0.2.0post2 on 2026-03-14. The last push to the default branch is dated 2026-03-21, a week after the newest tag and a fortnight after the newest announcement, so that final week of work is undocumented in the visible news. For a reader deciding whether to depend on this, the practical statement is that it is a roughly one-week-old project, and the default branch has been quiet since 2026-03-21.

Four of the seven comparison rows are identical across all five projects

The feature table sets Aurogen against OpenClaw, NanoBot, PicoClaw and ZeroClaw, and the interesting reading is what it does not distinguish. Memory, Tools and Skills, and Sub-agents are marked present in all five, so three rows carry no information at all. A fourth row, the Web panel, is present in Aurogen and OpenClaw but absent in the other three. That leaves the capability Aurogen claims over its upstream down to two rows: multi-agent that is not a sub-agent, and multiple instances per channel. BOOTSTRAP is shared with OpenClaw, and the hardware row is the only one with figures, ranging from a Linux board at about ten dollars to a Mac Mini at 599. The table carries its own caveats, noting that NanoBot has partial multi-instance support with involved configuration, and warning that the surveyed projects keep changing so the table may go out of date quickly.

docker compose publishes port 80 and the documented URL is 8000

Two deployment paths, two ports, and the text points at the wrong one for the second. The plain Docker run is explicit:

docker run --rm -p 8000:8000 \
  -v "$(pwd)/aurogen/.workspace:/app/aurogen/.workspace" \
  aurogen

with the instruction to visit `http://localhost:8000` afterwards. The Compose section then says only that from the project root you run `docker compose up -d --build`, and its compose file publishes `80:8000`. So the Compose deployment serves on port 80, while the only URL in the documentation says 8000. The two paths also differ in durability, since the compose service sets a restart policy and the `docker run` example passes `--rm`. Nothing in the visible documentation mentions the discrepancy, which makes it the first thing to check if a Compose install appears to be down.

The image build falls back from npm ci to npm install

The Dockerfile is a two-stage build on a combined Python and Node image. The builder stage installs the frontend from its lockfile, then builds a WhatsApp bridge, and for the bridge it runs a single line that matters: `npm ci` with its errors sent to null, falling back to `npm install` if it fails. That is a common shortcut and it has a cost. A lockfile that does not match the manifest, or a registry hiccup, does not fail the build; it produces a resolution that is not the one the lockfile described, silently, inside an image nobody inspects. The frontend build does not take that risk, and the runtime stage copies the bridge's node_modules into the final image, so the non-reproducible resolution is what ships. The rest of the build is careful, with an empty `VITE_API_BASE_URL` so the frontend uses relative paths, and a workspace directory pre-created for the volume to mount over.

A WhatsApp bridge is built into the image and named nowhere in the features

The bridge is a whole second Node project inside the Python application. The builder copies `aurogen/channels/bridge/package.json`, runs the install, builds it, and the runtime stage then copies the bridge's dist output, its node_modules and its manifest into the final image. That makes Node a runtime dependency of a Python service, and it makes a WhatsApp channel a shipped capability. The feature list never mentions it. The three stated characteristics are full modularity across agents, channels, providers and skills, easy configuration through a web panel, and ecosystem compatibility with OpenClaw skills from clawhub.ai, and channels appear there only as one of the concepts being modularised. A reader auditing what the image contains would find a messaging integration the README does not describe.

macOS is Apple Silicon only, and the packages bundle both runtimes

Four release artifacts are listed: macOS on Apple Silicon for M1 through M4 as an arm64 tarball, Linux arm64, Linux x86_64, and Windows x64 as a zip. There is no macOS Intel build and no Windows arm64, while Linux is the only platform with both architectures covered. Each package includes Python and Node.js runtimes so no additional installation is needed, which is a real convenience and also explains why the image can carry the bridge. On macOS and Linux you extract the tarball, change into the directory and run `bash start.sh`; on Windows you extract the zip and double-click `start.bat`. Everything then happens at `http://localhost:8000`. For development the path is conventional rather than bundled: a conda environment on Python 3.12, pip install from the backend requirements, uvicorn serving the app on port 8000 with reload, and npm install plus a dev script for the frontend.

The architecture section is a placeholder and build/ is committed at the root

Two things about the repository tell you how finished it is. The architecture section contains one sentence under a heading, that the diagram is a rough draft and a cleaner version is coming soon, and the feature comparison ends by saying more unique features will be documented as the project evolves. So the two sections a reader would use to understand the design are both forward-looking. The tree is also worth a look: alongside the Dockerfile, compose file, assets, docs and the two application directories, there is a `build/` directory at the root whose purpose is not stated, which is also the path the Dockerfile builds inside the container, and there is no `.github/` directory, so nothing in the repository records how the release artifacts are produced. The documentation itself lives on a separate host rather than in the repository.

Editorial conclusion

Use Aurogen if you specifically want several agent instances sharing a channel, since that is the capability the comparison table claims over the upstream project and the reason the reimplementation exists. Do not adopt it on the strength of the documentation's completeness, because the architecture section is an empty placeholder, the feature list never mentions the WhatsApp bridge the image builds, and the comparison table's first four rows are identical across all five projects it surveys. Verify three things first, and in this order: that your platform has a release artifact, since macOS is Apple Silicon only while Linux covers both architectures, that your Compose port matches what you will type, and that the last push is dated 2026-03-21, roughly six months before this, so treat it as a prototype rather than an infrastructure dependency.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. UniRound-Tec/Aurogen on GitHub