botmaker - Moses Yebei

The Problem

Running OpenClaw AI chatbots in production means managing Docker containers, per-bot credentials, multi-provider model config, and a dozen chat channels — all by hand. BotMaker wraps that into a web UI with a creation wizard, monitoring dashboard, and container lifecycle management.

What This Does

A two-part app. The backend (src/) is a Fastify server with SQLite for bot metadata, Dockerode for container orchestration, and file-based per-bot secrets. The frontend (dashboard/) is a React + Vite SPA with a multi-step wizard covering templates, personality, toggles, and channel/model config — 28 channel definitions live in dashboard/src/config/channels/, four providers in dashboard/src/config/providers/.

Bot config is generated from templates in src/bots/templates.ts (generateOpenclawConfig, generateSoulMd, generateIdentityMd). Secrets are isolated per bot in src/secrets/manager.ts and mounted read-only into containers.

How It Is Wired

Execution starts at main in src/index.ts:12, which reaches 28 functions and calls buildServer (src/server.ts:81). The shortest path to a side effect: main -> buildServer -> initDb -> createSchema, hitting the database via db.exec in src/db/schema.ts. The shutdown path (main -> shutdown -> listBots) hits the DB via db.prepare. Eleven functions read or write the database; one runs an external command.

The hot functions — change these and the most breaks: getDb (called from 8 places), useWizard (7), wrapDockerError (7), handleResponse (5), getSecretsRoot (5). dashboard/src/config/channels/types.ts is a hub with 31 modules importing it and zero outgoing edges — pure type definitions, but high-blast-radius churn. dashboard/src/types.ts has 15 importers.

File-by-file map: src/bots/store.ts owns bot CRUD, src/services/DockerService.ts owns container lifecycle (11 functions), src/services/ReconciliationService.ts syncs status and cleans orphans, src/db/index.ts owns the SQLite handle, dashboard/src/api.ts is the frontend's HTTP layer, dashboard/src/wizard/context/WizardContext.tsx holds the wizard state machine (5 functions, called from 6 files).

How To Use It

npm install
cd dashboard && npm install && cd ..
npm run dev          # backend with hot reload, port 7100
cd dashboard && npm run dev   # frontend

# Production
npm run build:all
npm start

# Docker
docker compose up -d

Configuration lives in env vars: PORT, DATA_DIR, SECRETS_DIR, OPENCLAW_IMAGE, BOT_PORT_START. Requires Node 20+, Docker, and an openclaw:latest image.

Real-World Use

A team offering per-customer OpenClaw bots: each customer gets an isolated container on its own port. The wizard generates a bot with provider credentials (OpenAI, Anthropic, etc.) and channel tokens (Telegram, Slack, WhatsApp). Secrets land in SECRETS_DIR per bot, mounted read-only — a container compromise doesn't expose other bots' credentials. The dashboard's diagnostics tab shows container stats and lets an operator clean orphaned containers/workspaces.

Code Health & Issues

Static analysis found 7 findings (2 high, 5 medium): hub modules with high blast radius in channels/types.ts and types.ts; 23 duplicated 6-line blocks across 12 files (e.g. BotCard.tsx exists in both components/ and dashboard/); high branching density in src/bots/store.ts (50 branch points over 145 lines); deep nesting in dashboard/src/wizard/pages/Page4Config.tsx (indentation depth 6).

SDLC observations: no CI workflow despite 115 source files; docker-compose.yml runs privileged with the Docker socket mounted and host networking; the Dockerfile bakes SECRETS_DIR as an env var (readable via docker history); node:20-slim is unpinned; no non-root USER; 4 test files against 115 source files (ratio 0.035); missing .editorconfig and .gitattributes.

The Bottom Line

Solid architecture for the problem: clean separation between backend, dashboard, and per-bot secrets, with a genuinely useful wizard. The gaps are operational — no CI, privileged Docker, unpinned images, thin test coverage. Fine for a single-host deployment today; needs hardening before multi-tenant or shared-host use.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

196 files

TypeScript69
TSX44
CSS41
Markdown24
JSON8
Shell3

ReactDocker

Module dependencies

The 10 most depended-upon modules of 115, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_rd_src_config_channels_types["types"] n1_dashboard_src_types["types"] n2_wizard_context_WizardContext["WizardContext"] n3_dashboard_src_ui_Panel["Panel"] n4__src_wizard_components_index["index"] n5_d_src_config_providers_types["types"] n6_dashboard_src_ui_Button["Button"] n7_d_src_config_providers_index["index"] n8_dashboard_src_api["api"] n9_dashboard_src_ui_StatusLight["StatusLight"] n8_dashboard_src_api --> n1_dashboard_src_types n7_d_src_config_providers_index --> n5_d_src_config_providers_types n9_dashboard_src_ui_StatusLight --> n1_dashboard_src_types n2_wizard_context_WizardContext --> n1_dashboard_src_types n2_wizard_context_WizardContext --> n7_d_src_config_providers_index

Findings

MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high4

medium4

low1

Add a workflow that builds and tests this repositoryhigh

115 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Drop privileged mode and host networkinghigh

docker-compose.yml

the docker socket mounted

privileged hands the container every capability including direct device access, which makes escaping to the host a documented one-liner, and host networking removes the network boundary so every port the container opens is open on the host.

Fix: Grant the specific capability the workload needs with cap_add, and publish ports explicitly.

Add a build gate for the deployable artifacts herehigh2 occurrences

Dockerfile

deployment artifacts with no workflow

Something in the repo is meant to reach a server and no automated step has ever validated it, which is the state of 125 repositories here.

Fix: Add a workflow that at least builds the image and validates the manifests.

Stop passing the secret as a build argument or image envhigh

Dockerfile

ENV SECRETS_DIR with a baked value

ARG and ENV values are recorded in the image layers, so the credential is readable with docker history by anyone who can pull the image, and deleting the file in a later layer does not remove it.

Fix: Mount it at build time with --mount=type=secret, or inject it at run time.

Enable Dependabot or Renovatemedium

2 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium2 occurrences

Dockerfile

node:20-slim, node:20-slim

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Add a non-root USER to the imagemedium

Dockerfile

CMD or ENTRYPOINT with no USER directive

A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.

Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.

Expand the test suite; it cannot cover this codebasemedium4 occurrences

4 test files against 115 source files (ratio 0.035)

A reviewer reads "has tests" and assumes a safety net that covers two files out of eighty-five, which is how untested paths ship behind a green badge.

Fix: Add tests for the highest fan-in modules first.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.