cxbdia's avatar

Running Laravel Boost + Claude MCP in Docker setup - Not working

I’m trying to set up Laravel Boost with Claude MCP in a Dockerized environment, and I keep running into friction. Here’s my setup and the challenges:

  • Claude code runs on my host machine.
  • Laravel runs inside a PHP container (php artisan serve) inside Docker.
  • I’m using .env variables that point to other Docker services (Redis, MySQL, etc.).

Here are the approaches I’ve considered and why they’re tricky:

Run Boost outside Docker

Boost can run on the host, but it fails to connect to Dockerized services: php_network_getaddresses: getaddrinfo for redis failed: nodename nor servname provided, or not known

Run Boost inside Docker

Boost communicates over stdio only. Claude MCP expects stdio communication as well. stdio is local to the process and cannot cross container boundaries, so my host-based Claude client cannot connect directly.

Run Claude inside Docker

This would solve the stdio issue, but I have 12 other Laravel projects, and running Claude Code in each container and logging in separately is not practical. I prefer keeping Claude Code on the host.

Abandon Docker / use Laravel Herd

This would ensure both CC and Boost runs on the same host BUT it is not feasible; my team relies on Docker to keep development environments consistent across 10 developers.

Use socat to expose stdio over a port

I tried to expose the Laravel Boost MCP server running inside Docker over a TCP port using socat, like this:

php artisan boost:mcp | socat - TCP-LISTEN:4000,reuseaddr,fork

Claude MCP does not support TCP/port communication for stdio servers. It only talks to processes it launches locally over stdin/stdout.

At this point, I’m stuck.

1 like
4 replies
LaryAI's avatar
Level 58

Here’s a breakdown of the problem and some potential solutions:

Problem Summary:

  • Laravel (and Boost) inside Docker; Claude MCP/Code on host.
  • Boost and Claude use stdio for communication (cannot connect across containers or between host/container).
  • You want to keep Claude on the host but allow Boost (in Docker) to talk to it.
  • Docker network aliases for databases, etc., don’t work for host programs.
  • You don’t want to duplicate Claude container for every app.

Solution 1: Use Host Networking for Boost (Not Recommended for Mac/Windows)

Host networking (--network=host) allows container to see the host’s network—but generally only available on Linux, and even then it exposes security risks and can cause port conflicts.

Solution 2: Socket or TCP Proxy Bridge for Stdio

Since stdio can’t cross the host/container boundary, use a small proxy to bridge the gap:

A. Run Boost on Host (with a TCP connection instead of stdio):

See if Boost supports any form of TCP communication or WebSocket instead of only stdio. If so, you could run Boost on your host and point it at your Dockerized services by setting .env variables to the host address.

But, for many Boost setups, only stdio is expected.

B. Pipe stdio Across the Boundary with a Proxy

  1. Create a Local Proxy Script
    Use socat or a small Node/Python script to bridge stdio (Claude <-> Boost):

    • On your host, run Claude as usual (it listens on stdio: pipes).
    • Also run a TCP proxy that listens on a port and forwards input/output to Claude’s stdio.
    • In Docker, run Boost and configure it to use a TCP connection to the host (if possible).
    • If Boost only does stdio, you may need another containe/local process that proxies stdio to TCP (a wrapper script).
  2. Example socat bridge (host):

    socat -d -d TCP-LISTEN:9001,reuseaddr,fork EXEC:"path/to/claude-mcp"
    

    Now, in Docker, connect Boost to host.docker.internal:9001 (this keyword works on Mac/Windows Docker).

    If Boost does not support TCP at all, you will need to wrap it in a small script/program that connects stdio to TCP.

C. Use Unix Domain Sockets

If your host is Linux, you can also sometimes mount a Unix socket into both your container and host, but this is more complex and less portable.

Solution 3: Centralized Claude Service, Projects Connect by TCP

Run one Claude MCP/Code service on your host, expose a local TCP port, and have all your projects connect to that host:port (not by stdio). Use the same socat trick above.

Docker-to-host connectivity:

  • In Docker, instead of localhost or 127.0.0.1, use host.docker.internal (on Mac+Windows), or your host’s IP (on Linux).
  • Set your Laravel/Boost configs to use this TCP port.

Solution 4: Custom Wrapper

Write a small wrapper in Node.js, Python, or even PHP that:

  • Listens to a TCP port (from inside Docker).
  • Pipes TCP input/output to the local Claude process’s stdio.

Example (Node.js pseudo-code):

const net = require('net');
const { spawn } = require('child_process');

const claude = spawn('path/to/claude-mcp');
const server = net.createServer(socket => {
  socket.pipe(claude.stdin);
  claude.stdout.pipe(socket);
});
server.listen(9001);

Now, Boost in Docker connects to TCP port 9001 on the host.

Summary

There’s no perfect solution unless Boost/Claude add true TCP support. The most robust current option:

  1. Run Claude on host, and bridge stdio to TCP with socat or a small script.
  2. In Docker, connect to host.docker.internal:9001.
  3. If Boost requires stdio inside Docker, wrap it similarly with a proxy on the Docker side.

TL;DR:
You need a TCP bridge/proxy that speaks stdio with Claude, and a way for Boost inside Docker to use TCP to talk to that proxy.


Further Reading/References:

Ask your team: If you find stdio too limiting, it may be worth opening a feature request with Boost/Claude for proper TCP or Unix socket support.


Sample Docker Compose snippet for Boost:

services:
  laravel:
    build: .
    environment:
      - REDIS_HOST=redis
      - CLAUDE_HOST=host.docker.internal
      - CLAUDE_PORT=9001
    # ...etc

Let me know if you need a full proxy implementation!

cxbdia's avatar

None of these solutions are working. They’re mostly just the standard suggestions AI keeps regurgitating, which I’ve already tried.

I’m also wondering how feasible it would be to run a centralized Laravel Boost service for our company. The idea would be to maintain a single knowledge base for Laravel Boost, enforce our own rules, and have Claude code reference that central service.

cxbdia's avatar
cxbdia
OP
Best Answer
Level 3

Finally, this worked:

change the .mcp.json file after boost install to:

{
  "mcpServers": {
    "laravel-boost": {
      "command": "docker",
      "args": ["exec", "-i", "<your docker container name>", "php", "artisan", "boost:mcp"]
    }
  }
}
1 like
Latinvm's avatar

As I am running VS Code direcly from WSL2 (code . ) I ran into a similar issue.

I changed the configuration to simply work within WSL2:

{
    "servers": {
        "laravel-boost": {
            "command": "/usr/bin/php8.3",
            "args": [
                "/var/www/domain.local/artisan",
                "boost:mcp"
            ]
        }
    }
}

This did the trick, MCP is now running correctly and claude code can find it:

I hope this helps someone :)

Please or to participate in this conversation.