“Self-hosted” answers where a process runs. It does not automatically answer where every piece of data goes. A coding runner can execute on your machine while still sending prompts and selected repository context to an external model provider.

Separate three locations

The control plane coordinates work and records delivery state. The runner checks out code, starts tools, and performs configured operations. The model provider handles inference for requests made by that runner. Review all three when evaluating privacy requirements.

Keeping an API key on the runner avoids sending that key through the web application. It does not mean the provider sees no source context. Similarly, a control plane that is not a repository checkout may still receive issue descriptions, artifact contents, or log excerpts. These distinctions belong in deployment documentation, not just a marketing label.

Treat the runner as an execution host

Repository scripts and tools can exercise the permissions available to the runner process. Separate Git worktrees reduce checkout collisions, but they are not a security sandbox. Use a dedicated machine or appropriately constrained environment when the repository or its commands are not fully trusted.

Docker access also deserves a separate review. The Docker security documentation explains the importance of daemon access and host-level isolation choices. A container-related checkbox should not be interpreted as a guarantee that arbitrary code cannot affect the host. See Docker Engine security.

Start with explicit operation

Pair the runner, configure the provider, verify prerequisites, and leave automatic startup off during initial testing. A storage check can confirm a key is readable without calling a model. A heartbeat can confirm enrollment without claiming a task. Actual work start is a different action and can incur charges.

A deployment checklist

  • Decide which repositories and commands the host may execute.
  • Understand what context each provider request can include.
  • Keep credentials out of repository files and diagnostic exports.
  • Review evidence retention and organization access.
  • Test pause, restart, and failure recovery before unattended use.

ForgeLoop's security overview explains these boundaries for its control plane and runner model. Local execution is a useful control, but responsible operation still depends on the environment you give it.