About Golemcore Bot
Golemcore Bot is an MCP server published by alexk-dev in the AI category: agent Platform for AI-Native Companies.
The repository has 41 stars and 6 forks, with the last commit 2 months ago. Recent commit activity is the strongest signal that reported issues will get attention.
Install
git clone https://github.com/alexk-dev/golemcore-botThis server has no ConduID identity, so agent calls to it are not receipted. Pin the version you install and review the source before granting it credentials.
Ask AI
Ask AI about Golemcore Bot
Powered by Claude · Grounded in docs
Security checks
Static checks derived from the repository 3 hours ago. Heuristics on the source, not an audit.
- ✓README presentThe repository ships documentation.
- ✓License declaredUsable under a stated license.
- ✓Tests presentA test suite exists in the repository.
- ✓Dependencies pinnedA lockfile pins dependency versions.
- ✓No dynamic code executionSource scan found no eval, dynamic Function, or shell execution.
- !Scoped permissionsDoesn't declare a permission scope. Assume it can do anything its process can.
Releases
README
GolemCore Bot
Agent Platform for AI-Native Companies — build, run, extend, and inspect channel-connected agents with skills, plugins, MCP, memory, and Hive.
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=256mand--cap-add=SYS_ADMINare 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.
Build it locally
./mvnw clean package -DskipTests -DskipGitHooks=true
npx golemcore-bot-local-build-native-dist
This produces an archive in:
target/native-dist/golemcore-bot-<version>-<platform>-<arch>.tar.gz
What is inside
The app-image contains:
- a small launcher application produced by
jpackage - 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 runtimeweb --port=<port>— forwards-Dserver.port=<port>to the spawned runtimeweb --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 pathweb -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.txtupdates/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.
- Optionally enable Telegram, install plugins, connect MCP-backed skills, or join Hive.
For runtime config details, storage layout, and browser or sandbox notes, see Configuration.
Documentation
Documentation site: https://docs.golemcore.me/
The source docs below are kept in this repo for local and offline reference:
- Quick Start
- Skills
- Tools
- MCP Integration
- Model Routing
- Memory + RAG
- Auto Mode + Delayed Actions Design
- Hive Integration
- Webhooks
- Deployment
- Dashboard
Contributing / Support / License
- Contributing: see CONTRIBUTING.md (workflow, quality gates, tests).
- FAQ: FAQ.md.
- Issues: https://github.com/alexk-dev/golemcore-bot/issues
- License: Apache 2.0 — see LICENSE and NOTICE.
⭐ Star this repo if you find it useful!
Made with ☕ and 🤖
README fetched from the repository 3 hours ago. The original is authoritative.