containerized-agents

OpenCode with its dependency MCP services, run as Docker containers.

Migrated from genji1024/dotfiles (.dockerscripts + OpenCode config). This repository contains only what OpenCode needs: the compose file, the Dockerfiles for OpenCode and the 5 MCP servers, and the OpenCode agent/config files. The shell wrappers from dotfiles are intentionally not included.

Services

docker compose -f compose.yaml config --services lists:

• common — base service (extended by opencode)
• opencode — OpenCode (port 4966, the only host-exposed port). Runs its own nested Docker daemon (Docker-in-Docker) so the docker CLI is available directly.
• gitlab-mcp, github-mcp, sessions-mcp, forgejo-mcp, gitpush-mcp — MCP servers, reachable on the internal network only

Getting Started

Prerequisites

• Docker with Compose v2
• A .env file copied from .env.example with real secrets (.env is git-ignored)

Prepare host directories

OpenCode and its MCP services bind-mount these directories. Create them first:

mkdir -p ~/.agents \
  ~/.cache/opencode \
  ~/.config/opencode \
  ~/.local/share/opencode \
  ~/.local/state/opencode

~/.config/opencode holds opencode.jsonc and agents/; ~/.local/share/opencode holds the session database that sessions-mcp reads.

Run OpenCode

No wrapper scripts are provided; launch the stack directly with Compose:

docker compose -f compose.yaml run --rm --service-ports opencode

run brings up depends_on services (the 5 MCP servers) automatically and waits for their healthchecks before starting OpenCode. --service-ports publishes port 4966.

Configuration

• .env.example — copy to .env and fill in the 6 variables (GitLab/GitHub/Forgejo tokens, STREAMABLE_HTTP_AUTH_TOKEN, FORGEJO_URL).
• .config/opencode/opencode.jsonc — MCP wiring for the 5 servers, permission allow-all, built-in agents disabled. Agent definitions live as Markdown files under .config/opencode/agents/.

The opencode container runs Docker-in-Docker (docker:27-dind base image + privileged: true). Inside the container the docker CLI talks to its own nested daemon. Build contexts under ~/repos/ resolve correctly because ~/repos/ is bind-mounted at the identical host path. Note that privileged DinD grants container-level root on the host kernel; keep this in mind when running untrusted builds.