Simplify setup and usage of this by packaging it in a docker container

[dchuk]

This is a cool project (and will be awesome once chunking and vector search is added).

You should consider packaging the whole server in a single docker image, so that it’s much easier for people to pull and run and not have to worry about dependencies and stuff.

While this is focused on Go, this article covers it well: https://k33g.hashnode.dev/creating-an-mcp-server-in-go-and-serving-it-with-docker

[Shubham-Khichi]

yeah I have been thinking about dockerizing this entire thing, I might give this task to Cline to do it for me, if you have the ability to do it before that would be nice. Make a PR.

[nevermore23274]

I'm working on this now, but it's not quite as easy as the article would make it sound.

Best bet would be to use compose, and have a networked backend/frontend with frontend being exposed on some localhost port. (this would also set it up to be allowed to be hosted as well)

Issue is, I think there's still other things being ironed out.

[Shubham-Khichi]

I concur, dockerization would be a good step once I have vector storage and other things incorporated too. Bigger problem might be the MCP server communicating with Claude or cline because it needs to be local but idk if opening up sockets would deter MCP connections. That's why I have been cautious.

[nevermore23274]

What I have right now works, but:

devdocs  |  ○ Compiling / ...
devdocs  |  ✓ Compiled / in 6.6s (1312 modules)
devdocs  |  GET / 200 in 7307ms
devdocs  |  ✓ Compiled in 759ms (656 modules)
backend  | INFO:app.main:Project root directory: /app
backend  | INFO:     172.18.0.1:59456 - "GET /api/mcp/config HTTP/1.1" 200 OK
backend  | INFO:app.main:Checking MCP server status
backend  | INFO:app.main:MCP server is not running
backend  | INFO:     172.18.0.1:59458 - "GET /api/mcp/status HTTP/1.1" 200 OK
backend  | INFO:app.main:Fetching MCP server logs
backend  | INFO:app.main:No log file found
backend  | INFO:     172.18.0.1:59468 - "GET /api/mcp/logs HTTP/1.1" 200 OK
devdocs  |  ✓ Compiled /api/storage in 425ms (1317 modules)
devdocs  |  GET /api/storage 200 in 544ms
devdocs  |  GET /api/storage 200 in 20ms
devdocs  |  GET /api/storage 200 in 23ms

So you can see the MCP server is an issue. I'm trying to work through it now, but think just attaching another container to the docker-compose and linking it into the network should be fine.

I could also just push this if others would like to contribute.

[Shubham-Khichi]

@nevermore23274 any updates on the docker optimization?

[monkeydust]

Also interesting in docker - on windows and cant get this to work using setup guide

[Shubham-Khichi]

Also interesting in docker - on windows and cant get this to work using setup guide

I'm working on it, what's the problem you are having with setup guide?

[monkeydust]

Also interesting in docker - on windows and cant get this to work using setup guide

I'm working on it, what's the problem you are having with setup guide?

thanks. So running ./start.sh doesn't launch the service on windows

[nevermore23274]

I have a docker compose that spins up three individual containers: Frontend, Backend, mcp. It then networks the containers together so they all have access to one another. The issue we have is how the mcp server works. It's basically made to interact with and then stop. This doesn't work well with docker, as you can't just spin up a container and close it over and over. Which is why during build, after installing the containers requirements you see this:

So I'll need to look into the mcp server itself.

[Shubham-Khichi]

I have a docker compose that spins up three individual containers: Frontend, Backend, mcp. It then networks the containers together so they all have access to one another. The issue we have is how the mcp server works. It's basically made to interact with and then stop. This doesn't work well with docker, as you can't just spin up a container and close it over and over. Which is why during build, after installing the containers requirements you see this:

So I'll need to look into the mcp server itself.

Yes the MCP server was designed to work locally hence the challenge with containers. Locally is essential to enable Claude desktop and cline to interact with it.

Have you thought of keeping the MCP server local and moving the entire application into docker? Maybe that would solve the issue

[nevermore23274]

I have a docker compose that spins up three individual containers: Frontend, Backend, mcp. It then networks the containers together so they all have access to one another. The issue we have is how the mcp server works. It's basically made to interact with and then stop. This doesn't work well with docker, as you can't just spin up a container and close it over and over. Which is why during build, after installing the containers requirements you see this:

So I'll need to look into the mcp server itself.

Yes the MCP server was designed to work locally hence the challenge with containers. Locally is essential to enable Claude desktop and cline to interact with it.

Have you thought of keeping the MCP server local and moving the entire application into docker? Maybe that would solve the issue

Realistically, your issue is here: https://github.com/cyberagiinc/DevDocs/blob/main/fast-markdown-mcp/src/fast_markdown_mcp/server.py

I haven't looked at this in a bit just, but looking over it now I believe there's a way to keep the server running continuously rather than what it does right now. (where it starts, does what it's supposed to, then stops)