Integrations

Colony’s core integrations are the code host, the repository workspace, configured review commands, and the model executor. Deployment guides describe credentials and setup; this page explains which system owns which behavior.

Code hosts

Self-hosted Colony has provider implementations for GitHub and Azure DevOps. Through them, Colony can work with issues or work items, comments, labels or tags, branches, pull requests, reviews, and merge operations. Provider capability is not identical: verify the feature you plan to use instead of assuming every GitHub event or review feature has an Azure DevOps equivalent.

GitHub is currently required for the automatic external PR review behavior described in External PR Review.

The code host is authoritative for source code, pull-request state, provider checks, protection rules, and whether a merge is permitted. Colony’s Pipeline Store is authoritative for Colony workflow state. State labels are projections into the provider; arbitrary label changes do not move a pipeline issue. Explicit controls such as colony:enqueue and slash commands are handled separately.

Deterministic review commands and provider CI

Two layers are easy to confuse:

1. Configured review commands. The Review executor runs commands from review.checks in a prepared worktree. If lint, test, type-check, security, or build commands are not configured there, the executor does not invent them.
2. Provider checks and protection. CI systems attached to the code host run on Colony PRs as configured by the repository. Required checks and branch protection can prevent the provider from accepting a merge.

These layers complement each other but are not the same. A locally configured review command can fail before an LLM review, while a provider check can complete later and still block merge. See Configuration Schema for check configuration.

Human-facing events

The code host remains the primary collaboration surface. Colony posts analyzer questions, status comments, reactions, pull-request reviews, and projected labels or tags there. Normal code-host notification settings determine who receives those events.

Self-hosted monitoring can also deliver configured Slack alerts and daily or weekly digests. Those channels are operational telemetry, not a universal per-team escalation router, and they must be configured explicitly. Cloud notification capabilities can differ; use the current Cloud pages for what is available in that service.

Dashboard identity

Authentication and organization roles are deployment concerns, not pipeline semantics. Do not infer SAML, OIDC, role mapping, or plan availability from the existence of a dashboard. Follow the current setup and account documentation for your deployment.

Setup

• Self-Host — installation, provider credentials, runtime configuration, and monitoring
• Cloud — current hosted-service onboarding and account capabilities
• Configuration Schema — self-hosted integration fields and defaults