Skip to content

For DevOps

kartoza-mcp is built to be boring to deploy. One static binary, stdio-only, no shared libraries, no database, no network listener — that last point matters: MCP servers attach to a client process, they don't listen on a port.

  • Deployment

    Distribute the binary to engineers, the org, or end-user laptops. Pick from package, image or release-artifact patterns.

    Deployment

  • Docker & containers

    Build a FROM scratch image under 10 MB. Run it from Claude Desktop, Gemini CLI or your own bridge.

    Containers

  • Systemd

    Long-running bridges and supervisors when you fan a single MCP server out to many clients via socket activation.

    Systemd

  • Observability

    Logs over stderr. Wiring those into your logging stack. What to measure.

    Observability

  • Security

    Threat model: stdio MCP servers are post-trust. What the boundary is, and how to harden it.

    Security

Deployment shapes at a glance

flowchart LR
    subgraph laptop["Engineer laptop"]
      L1[Claude Desktop] -->|stdio| L2[kartoza-mcp]
    end
    subgraph server["Shared bridge host"]
      S1[mcp-bridge.service] -->|stdio| S2[kartoza-mcp]
      S1 -->|websocket| C1[Remote client]
      S1 -->|websocket| C2[Remote client]
    end
    subgraph k8s["Cluster"]
      P1[Pod: mcp-bridge] --> P2[Pod: kartoza-mcp]
    end

Pick the shape that matches your team:

  • Solo engineer / small team → install on each laptop.
  • Org-wide rollout → shared host running a bridge, MCP servers child-spawned per client session.
  • Cluster / SaaS → container per analytic, scaled horizontally.

No port to open

The server speaks JSON-RPC over stdin / stdout by design. There is no listening socket. Anything that "exposes" the tool to a network is a bridge you've added on top.