Containerized MCP runtime

FrootAI MCP for Docker

One container image for local stdio, remote HTTP, CI, and cloud operation.

Run the same FrootAI MCP process without installing Node.js on the host. Choose a disposable client-launched container or an operated HTTP service with explicit health and auth boundaries.

Open container package Setup guide

amd64 + arm64Stdio + HTTPVersion-pinnableMIT licensed

container · frootai-mcpREADY

ghcr.io/frootai/frootai-mcp

$ docker run --rm -p 3000:3000 \
  ghcr.io/frootai/frootai-mcp:latest http

transport  HTTP
port       3000
health     /healthz
readiness  /readyz
✓ FrootAI MCP ready

Choose the transport

Disposable stdio or operated HTTP

The image is the same. The lifecycle, client configuration, and security responsibility are not.

Stdio

A local MCP client launches the container and communicates over standard input/output.

docker run -i --rm ghcr.io/frootai/frootai-mcp:latest

HTTP

Run a long-lived remote MCP process for shared clients, Container Apps, or Kubernetes.

docker run --rm -p 3000:3000 ghcr.io/frootai/frootai-mcp:latest http

Connect a client

Launch locally or point to a service

.vscode/mcp.json · stdio

{  "servers": {    "frootai-docker": {      "type": "stdio",      "command": "docker",      "args": ["run", "-i", "--rm", "ghcr.io/frootai/frootai-mcp:latest"]    }  }}

Remote MCP client · HTTP

{  "servers": {    "frootai": {      "type": "http",      "url": "https://your-frootai-host.example/mcp"    }  }}

Deployment map

Four useful container boundaries

Local agent

VS Code, Claude, or Cursor launches one disposable stdio container.

CI isolation

Pin the image and run deterministic validation or MCP tasks inside a clean runtime.

Remote service

Expose HTTP behind your own TLS, ingress, and authentication boundary.

Cloud runtime

Use readiness and liveness probes with Container Apps or Kubernetes orchestration.

Operate the service

Health, readiness, and authentication are visible

HTTP mode is an operated service. Probe it, secure it, and keep its configuration outside the image.

Liveness

GET /healthz

Process status, version, uptime, and engine state.

Readiness

GET /readyz

Modules loaded, active sessions, and cache state.

API key mode

FAI_AUTH_MODE=apikey

Use a secret provider or environment file for keys.

Production-minded start

Pull, inspect, pin, then run

Terminal

docker pull ghcr.io/frootai/frootai-mcp:latestdocker image inspect ghcr.io/frootai/frootai-mcp:latest
# After review, pin an approved release tagdocker run -i --rm ghcr.io/frootai/frootai-mcp:<version>

HTTP with external secrets

docker run --rm -p 3000:3000   --env-file .env.frootai   ghcr.io/frootai/frootai-mcp:<version> http
curl --fail http://localhost:3000/healthzcurl --fail http://localhost:3000/readyz

Runtime boundary

Repeatable does not mean responsibility-free

Pin before production

Replace `latest` with a reviewed release tag for reproducible environments.

Keep stdin open

The `-i` flag is required when a local MCP client uses stdio mode.

Own remote security

HTTP mode still needs your TLS, ingress, network policy, and API-key handling.

Keep secrets outside config

Pass authentication through a secret store or environment file, not committed client JSON.

Network remains explicit

The image runs locally after pull; attached and upstream services retain their own network requirements.

Compare MCP modes Docker package decision