Repository navigation
Process compose option #71
Description
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.
Activity
Melodeiro commentedon Oct 15, 2025
Can't test it, but if you un-quarantine the MCP will it still run in docker?
joeblew999 commentedon Oct 16, 2025
You can run it without docker btw
I run it inside docker when I deploy to a cloud vm like fly.io
Dumbris commentedon May 1, 2026
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— nodocker_isolationrequired.process-composewould 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.
feat(sandbox): spike Landlock non-docker sandbox PoC (MCP-34.1) (#754)
Dumbris commentedon Jun 28, 2026
Update / resolution — non-Docker isolation now exists (native
sandboxmode)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-serverisolation.mode:dockersandboxsetrlimitresource 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{ "docker_isolation": { "mode": "sandbox" } }Unlike
process-compose,sandboxmode 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 asnone). 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-composeask remains won't-do), butsandboxmode should cover the non-Docker use case that motivated it. Ifsandboxmode doesn't fit your scenario, please open a new issue with the specifics.feat(security): scanner-flow parity under sandbox isolation + docs (M…
ci(sandbox): poll for running:True in health probe (fix MCP-3236 star…
ci(sandbox): check status.phase==Ready, not nonexistent running field
ci(sandbox): poll /readyz (controller-backed) for readiness
ci(sandbox): use docker_isolation.mode (global key) + assert sandbox …
ci(sandbox): MCP-3236 integration tests + workflow + snap-docker harn…