Agent Platform for AI-Native Companies — build, run, extend, and inspect channel-connected agents with skills, plugins, MCP, memory, and Hive.
Agent Platform for AI-Native Companies
ดาว
41
เครื่องมือ
—
อัปไทม์
—
What it is
GolemCore Bot is the agent platform for AI-native companies building on the GolemCore ecosystem.
Use it to run channel-connected agents, extend them with skills, plugins, and MCP servers, and operate them with memory, delayed follow-ups, trace inspection, and Hive-connected control flows.
Use it in two ways:
Run agents — chat in the dashboard, Telegram, or webhook-driven flows, then inspect execution, memory, and trace output.
Extend the runtime — add skills, install plugins, connect MCP servers, configure routing tiers, and attach Hive-based control and inspection.
Why it is different
Plugin-native runtime — plugins can contribute tools, channels, voice providers, and RAG ingestion instead of living outside the agent runtime.
MCP-ready by design — skills can launch MCP servers, and the runtime now includes MCP catalog and discovery flows.
Built for long-running work — delayed follow-ups, progressive memory orchestration, and recovery paths help agents continue past a single turn.
Hive-connected control surface — connect agents to Hive for control commands, lifecycle signals, inspection, and host-level coordination.
Inspectable execution — traces, waterfall views, and exported snapshots make agent behavior easier to debug and operate.
Quick start
What you need
Docker
At least one LLM provider API key
Run the published image
docker pull ghcr.io/alexk-dev/golemcore-bot:latest
docker run -d \
--name golemcore-bot \
--shm-size=256m \
--cap-add=SYS_ADMIN \
-e STORAGE_PATH=/app/workspace \
-e TOOLS_WORKSPACE=/app/sandbox \
-v golemcore-bot-data:/app/workspace \
-v golemcore-bot-sandbox:/app/sandbox \
-p 8080:8080 \
--restart unless-stopped \
ghcr.io/alexk-dev/golemcore-bot:latest
docker logs -f golemcore-bot
# Health probe:
# curl http://localhost:8080/api/system/health
#
# Compatibility: Docker CMD overrides may still pass Spring Boot args directly:
# docker run ... ghcr.io/alexk-dev/golemcore-bot:latest --server.port=9090
# Open http://localhost:8080/dashboard
# On first start, check logs for the temporary admin password.
Open http://localhost:8080/dashboard, sign in with the temporary admin password from the logs, then configure your LLM providers in Settings.
Why the extra Docker flags?
--shm-size=256m and --cap-add=SYS_ADMIN are needed for the Browser tool (Playwright/Chromium) in containers.
See Configuration → Browser Tool.
Optional next steps
Enable Telegram in Settings for channel-based chat.
Install plugins for browser, search, mail, weather, voice, or RAG-backed workflows.
Connect MCP-backed skills and tool servers.
Join Hive for control-plane coordination and inspection.
Need a local build, Compose setup, or production deployment path? See Quick Start and Deployment.
Local native app-image bundle (experimental)
Besides Docker and the plain executable JAR, the release workflow now also publishes a local app-image bundle for the current OS/architecture.
a bundled Java runtime, so running the extracted app-image does not require a separately installed Java
the regular self-updatable runtime jar under lib/runtime/
a picocli-powered native launcher entrypoint with built-in help and launcher-only options
launcher wiring that points to that bundled runtime jar first
So the startup order becomes:
staged update from updates/current.txt, unless the bundled runtime jar is newer
bundled runtime jar from the app-image
legacy Jib/classpath fallback
Native launcher options
The native launcher uses picocli, so it has first-class help and a small set of launcher-specific flags.
Show help:
./golemcore-bot/bin/golemcore-bot --help
Common options:
web — required command that starts the bundled Spring Boot runtime
web --port=<port> — forwards -Dserver.port=<port> to the spawned runtime
web --hostname=<address> — forwards -Dserver.address=<address> to the spawned runtime
--storage-path=<path> / web --storage-path=<path> — forwards -Dbot.storage.local.base-path=<path>
--updates-path=<path> / web --updates-path=<path> — forwards -Dbot.update.updates-path=<path>
--bundled-jar=<path> — overrides the bundled runtime jar path
web -J=<jvm-option> / web --java-option=<jvm-option> — forwards extra JVM options to the spawned runtime
The native package starts the Spring runtime with the prod profile by default.
Examples:
./golemcore-bot/bin/golemcore-bot web --port=8080 --hostname=0.0.0.0
./golemcore-bot/bin/golemcore-bot web -J=-Xmx1g --port=9090
./golemcore-bot/bin/golemcore-bot --storage-path=/srv/golemcore/workspace web --updates-path=/srv/golemcore/updates
Spring runtime arguments still work
Unknown arguments are forwarded to Spring Boot unchanged, so existing application arguments continue to work:
./golemcore-bot/bin/golemcore-bot web --server.port=9090
./golemcore-bot/bin/golemcore-bot web --spring.main.banner-mode=off
./golemcore-bot/bin/golemcore-bot web -Dlogging.level.root=INFO
If you want to make the split explicit, you can also use -- before Spring arguments:
./golemcore-bot/bin/golemcore-bot web --port=9090 -- --spring.main.banner-mode=off
Why this matters
This keeps the existing self-update model based on:
updates/current.txt
updates/jars/
while also letting the bot start cleanly from a native local bundle with documented launcher parameters.
First-run setup
Open the dashboard.
Add at least one LLM provider key in Settings.
Verify the storage and sandbox volumes are mounted so sessions, skills, and runtime config persist.