What runs on your infrastructure
AiOrch runs the orchestration service, agent processes, git worktrees, session state and event history on your machine, VM or build server. You choose the projects and provider endpoints. AiOrch’s service does not receive your repository source code as part of orchestration.
Self-hosting gives you responsibility for the host, project mounts, access controls, state backups and provider configuration. Separate agent worktrees organize changes; they do not establish a security sandbox by themselves.
Where traffic goes
| Component | Data and destination |
|---|---|
| Local orchestrator | Repository working copies, session state and logs remain in your configured local storage. |
| Configured inference providers | Receive the prompts and code context required by the tasks you run. Their data policies apply. |
| Local Ollama endpoint | Receives inference context on the infrastructure where you host that endpoint. |
| GitHub integration | Pushes branches and creates PRs when those delivery options are enabled. |
| License service | Receives activation and validation requests for licensing; it is separate from model inference. |
“AiOrch does not receive your source code” does not mean configured cloud models receive no code context. Review the provider’s terms and your own deployment requirements before sending a private project to that provider.
Worktrees and permissions are different boundaries
A git worktree gives an agent a separate checkout and branch. It reduces accidental edit collisions between tasks, but processes can still access other files made available to them.
Headless CLI execution requires explicit permission opt-in in the current runtime through ORCH_AGENT_SHELL_AFK. Enable it only after you understand the accessible files and permitted commands. Use narrow project mounts; avoid exposing home directories, credential stores, host toolchains or unrelated repositories to agents.
The orchestrator’s Docker socket access is mediated through its configured proxy. Do not add a raw Docker socket mount to the orchestrator or broaden container access to make a task succeed.
Use a dedicated development environment with only the repository and capabilities the task needs. Review generated changes and the final PR before merging them into your project.
Keep dashboard access private
The installer defaults to publishing on 127.0.0.1. A remote installation should use a deliberately configured private interface and an appropriate TLS-terminating reverse proxy. The application’s raw HTTP service is not a substitute for that transport protection.
Browser access uses the configured master-password login and signed session cookie; programmatic access uses an API key. Keep operator credentials and keys separate from source control. Restrict GitHub access to the intended repositories and necessary permissions.
Keep state and diagnostics under your control
Session state and structured event logs are stored on the configured filesystem. Persist the installation’s data volumes and include them in your backup policy before upgrades. Resumable state helps interrupted sessions continue, but it is not a replacement for backups.
Review logs and diagnostic exports before sharing them with support. Debug-level logging can contain provider payloads; do not assume every on-disk log is safe to publish. Keep API keys, licensing material, personal information and proprietary code out of public examples.
For execution checks and blocked delivery, see review and validation. Our privacy policy describes the applicable service data handling.
Documentation reviewed against the current v3 configuration and public installer. Options can vary by installed release.
Install & run your first session →Send documentation feedback