Spotted this while looking at the rmcp CVE alerts. The MCP HTTP transport binds 127.0.0.1 inside the container (src/mcp/mod.rs:80), so docker run -p 19280:19280 ... just connection-refuses. --network host works on Linux, but that isn't the usage shape we documented.
So the image ships DynamoDB but quietly drops MCP, which feels off given #3 frames it as drop-in dynoxide rather than drop-in DynamoDB only.
Rough thinking: probably wants a --mcp-host flag (default 127.0.0.1, image overrides to 0.0.0.0). Once that bind widens, allowed_hosts wants setting deliberately so we don't reopen the DNS rebinding hole the forthcoming rmcp bump closes.
Branch: feat/publish-docker-image.
Spotted this while looking at the rmcp CVE alerts. The MCP HTTP transport binds
127.0.0.1inside the container (src/mcp/mod.rs:80), sodocker run -p 19280:19280 ...just connection-refuses.--network hostworks on Linux, but that isn't the usage shape we documented.So the image ships DynamoDB but quietly drops MCP, which feels off given #3 frames it as drop-in dynoxide rather than drop-in DynamoDB only.
Rough thinking: probably wants a
--mcp-hostflag (default127.0.0.1, image overrides to0.0.0.0). Once that bind widens, allowed_hosts wants setting deliberately so we don't reopen the DNS rebinding hole the forthcoming rmcp bump closes.Branch:
feat/publish-docker-image.