Docker and Deployment

Docker and Deployment

Single container (Dockerfile)

docker build -t mcp-can .
docker run -d --name mcp-can -p 6278:6278 -p 5000:5000 -p 8080:8080 mcp-can

Base image: ubuntu:22.04. Installs Python 3 + venv, copies the project to /home/pi/MCP-Demo, installs it editable into /opt/venv, runs as a non-root appuser. MCP_CAN_CAN_INTERFACE=virtual/MCP_CAN_CAN_CHANNEL=bus0 are baked in as image env vars. A healthcheck polls TCP connectivity to port 6278 every 30s.

Worth verifying before relying on this: the image's CMD currently runs mcp-can server --port 6278 & mcp-can simulate && wait — i.e. the server and simulator as two separate process invocations inside the one container (backgrounded via shell &, not mcp-can demo). Given that the virtual CAN backend's shared state lives in the Python interpreter's own process (see Architecture / Troubleshooting), two separate mcp-can process invocations don't share it regardless of whether they're in the same container — the same limitation that affects two separate containers. If you build this image and the dashboard/tools show no traffic, that's the likely reason; the fix would be changing the CMD to run mcp-can demo --port 6278 as the single process instead.

Compose (docker/compose.yml)

cd docker
docker compose up -d --build

Runs server and simulator as separate containers, each built from the same Dockerfile/repo root, each setting MCP_CAN_CAN_INTERFACE=virtual/MCP_CAN_CAN_CHANNEL=bus0. This has the same cross-process limitation as above, just at the container level instead of the process level: separate containers definitely don't share the virtual bus unless the host provides a real shared vcan0 interface (SocketCAN), which this compose file doesn't provision. Until that's added, expect the server container's dashboard/tools to show no traffic against the simulator container.

Recommended today: use the single-container Dockerfile (once its CMD genuinely runs mcp-can demo, or adjust it yourself before building) rather than compose, until compose either provisions a shared vcan0 or is collapsed to a single combined service.

Real hardware / SocketCAN

Both can_interface/can_channel in Settings are pass-throughs to python-can, so socketcan/a real interface name works in principle — set MCP_CAN_CAN_INTERFACE=socketcan and MCP_CAN_CAN_CHANNEL=<your interface, e.g. can0>. This path isn't currently covered by an automated test or a dedicated guide in this repo (see Roadmap); if you're setting this up, python-can's own SocketCAN docs are the best reference for the OS-level vcan0/CAN adapter setup, since everything above that layer (DBC decoding, MCP tools, simulator protocols) is interface-agnostic.

PyPI

.github/workflows/release.yml builds and publishes on any v*.*.* tag push, via pypa/gh-action-pypi-publish. As of this writing, that workflow has never actually been triggered — no tags/releases exist, and the package isn't on PyPI yet. Before relying on it, confirm a PYPI_API_TOKEN repository secret is configured, then:

git tag v0.1.0
git push origin v0.1.0