Process compose option

[joeblew999]

I don’t know if this is useful but you can use process compose to at runtime spin up new processes.

https://github.com/F1bonacc1/process-compose

I use it to run many things cleanly inside a single docker , so there are less dockers.

I tap into it at runtime spin, to add and remove processes.

I am hoping that this could be considered as an alternative to docker . I know we loose isolation , and that defeats the purpose of the security design. However I really like this project , but don’t need the docker security isolation.

[Melodeiro]

Can't test it, but if you un-quarantine the MCP will it still run in docker?

[joeblew999]

You can run it without docker btw

I run it inside docker when I deploy to a cloud vm like fly.io

[Dumbris]

Thanks for raising this. After thinking it through we're going to stick with the Docker-isolation model as the primary sandboxing strategy — security isolation is a core pillar of mcpproxy (TPA protection, quarantine, sensitive-data detection all assume tools run in an isolated runtime).

For users who don't need isolation, you can already run upstream servers as plain stdio processes via mcpServers[].command — no docker_isolation required. process-compose would essentially duplicate that path without buying us the isolation guarantees.

Closing as won't-do. Reopen if there's a specific use case stdio-without-docker doesn't cover.

[Dumbris]

Update / resolution — non-Docker isolation now exists (native sandbox mode)

Revisiting this now that the underlying need — isolation without Docker — has been built directly into mcpproxy, which is a better answer than wrapping process-compose.

mcpproxy now has three isolation modes, selectable via docker_isolation.mode (global) or per-server isolation.mode:

Mode	What it does
docker	Container isolation (the original model).
sandbox	Native, no-Docker isolation — a Linux Landlock filesystem allowlist + setrlimit resource caps applied to the stdio server process before exec. Needs no Docker daemon and no user namespaces, so it works on hosts where the snap-docker + AppArmor conflict breaks Docker-based isolation.
none	No confinement.

{ "docker_isolation": { "mode": "sandbox" } }

Unlike process-compose, sandbox mode gives real OS-level confinement (write-path allowlist + resource limits), not just process supervision — so it preserves mcpproxy's isolation guarantee instead of duplicating the plain-stdio path. Honest limitation: it does not drop uid/gid without privilege, and it's Linux 5.13+ only (macOS/Windows treat it as none). Details + platform matrix: docs/docker-isolation.md.

The Docker-based security scanner plugins can't run under sandbox, so they degrade cleanly (skipped + security_scan.status: "degraded") rather than failing silently — that refinement is in #781. The sandbox launcher itself shipped in #768.

Leaving this closed (the specific process-compose ask remains won't-do), but sandbox mode should cover the non-Docker use case that motivated it. If sandbox mode doesn't fit your scenario, please open a new issue with the specifics.