The Problem
Self‑hosted AI assistants often rely on ad‑hoc file‑based “memory” and single‑user designs that break under concurrent use, lack proper scheduling, and expose security gaps. Teams that need isolated histories, reliable task execution, and a durable graph‑based knowledge store have few ready‑made alternatives.
What This Does
OpenLobster replaces OpenClaw’s flat‑file memory with a graph database (Neo4j) and a pluggable file backend (apps/backend/internal/application/memory/...). The codebase implements true multi‑user support: each user/channel is modeled as a distinct entity with its own conversation history (domain/models/user.go, domain/repositories/user/...).
A production‑grade scheduler lives in domain/services/scheduler/schedulerservice.go, exposing cron‑style recurring jobs and one‑off ISO‑8601 tasks, visible via the GraphQL UI (serve/graphql.go). The daemon entry points (apps/backend/cmd/openlobster/daemon/.go) launch the agent as a background service on Linux, macOS, or fall back to a stub on unsupported platforms.
How To Use It
Setup – Build the binary or container. Build locally go build -o openlobster ./apps/backend/cmd/openlobster
Or build a static Docker image
docker build -f .docker/Dockerfile.static -t openlobster:latest .
The Go module is defined in apps/backend/go.mod; dependencies are vendored via go.sum.
Configuration – Runtime settings are read by apps/backend/cmd/openlobster/config/config.go. Required fields (e.g., Neo4j URI, auth token) are expected as environment variables; the repo does not provide a sample .env, so operators must create one based on the struct fields in that file.
Running – Start the service with the compiled binary or Docker container. Binary ./openlobster daemon start # launches the platform‑specific daemon
Docker
docker run -d -p 8080:8080 \ -e NEO4JURI=bolt://neo4j:7687 \ -e NEO4JUSER=neo4j -e NEO4JPASS=secret \ openlobster:latest
The GraphQL endpoint is served by serve/http.go on port 8080, and the UI assets are under apps/backend/cmd/openlobster/public/.
Real‑World Use
A SaaS provider can deploy OpenLobster behind their internal network, configure separate Neo4j databases per tenant, and let each employee interact via Slack, Discord, or Telegram. The scheduler can trigger daily knowledge‑graph refreshes, while the per‑user histories keep conversations isolated.
query GetHistory($userId: ID!) { user(id: $userId) { conversations { id, messages { text, timestamp } } } }
Code Health & Issues
Low – Platform stub – daemon/unsupported.go logs “unsupported OS” but returns no error; invoking the daemon on an unknown OS will silently fail. Medium – Missing env‑var docs – config/config.go expects several variables (Neo4j credentials, API keys) but the repo lacks a .env.example or documentation of required names. Low – Limited test coverage for daemon – Tests exist for most domain services, but daemon startup (daemon/.go) has no unit tests, increasing risk of runtime regressions. Low – No vulnerability scanning – CI workflows include tests.backend-ci.yaml but no Dependabot or Snyk step; security of third‑party Go modules is not automatically checked. None – Structural health – go.mod, golangci.yml, and GitHub Actions pipelines are present; 60 test files run successfully in CI, indicating a mature test suite. None – Licensing – GPL‑v3 license is included (LICENSE.md), satisfying legal requirements.
The Bottom Line
OpenLobster delivers a solid, Go‑native backend for a self‑hosted AI assistant with graph‑based memory, true multi‑user isolation, and a built‑in scheduler. It is ready for containerized deployment, but teams must supply their own configuration (environment variables) and consider adding OS‑agnostic daemon tests and automated dependency scanning. Suitable for organizations that need controllable, multi‑tenant AI agents and can manage the required Neo4j infrastructure.