Where your data actually flows.
Loopthink always keeps a clean split: the control plane holds configuration, the tool catalog and permissions, never your payload. For execution you pick one of three optional paths per MCP group: managed in the EU cloud, a single runner in your network, or a gateway + worker split.
| Deployment | Where tools run | Runners | Data through Loopthink? | Best for |
|---|---|---|---|---|
1Managed Hosted for you in the EU | The Loopthink control plane executes the tool and applies masking. | None. Nothing to install. | Yes · masked in the EU | Fastest start; non-sensitive or already-cloud sources. |
2Self-hosted · Single runner One Loopthink Runner | One Loopthink Runner in your network executes the tool and masks locally. | 1 Loopthink Runner · executes + masks; outbound-only registration. | No · only the masked result leaves | Data residency for sensitive sources without a DMZ split. |
3Self-hosted · Gateway + Worker Two Loopthink Runners, two roles | One Loopthink Runner as gateway (public/DMZ, may sit outside your network) relays to a second one in your private zone that executes. | 2 Loopthink Runners · gateway relays, worker executes & polls outbound; nothing inbound reaches your zone. | No · never in the data path | Regulated environments with separated trust zones. |
The three paths are alternatives: you choose one per MCP group and can mix them across groups. In every mode the control plane stores only configuration, the tool catalog, permissions and the runner registry (endpoint + health). For self-hosted groups the plugin talks to your runner directly. Loopthink is never in the data path.
One control plane. Three optional paths.
Three optional paths, configured per MCP group, freely mixable across groups. Self-hosted paths use the same Loopthink Runner in different roles: in option 3 the gateway can sit in a DMZ or outside your network entirely, and only the worker touches internal systems, dialing out to the gateway. No inbound ports, no VPN, no firewall changes.