OSS, Cloud, or Colony-as-a-Service.
Three ways to run Colony. Same pipeline, same agents, same state machine — the difference is who operates the pipeline and who supplies the work. Hybrid tenancy (workers in your VPC) applies to Cloud and CaaS as a separate residency decision.
Clone, configure, run. Docker compose for local; Helm chart for k8s. Documented setup is two days of focused work.
GitHub App install plus a thirty-minute onboarding call. First merged PR within a week.
GitHub App install plus a kickoff workshop to scope the engagement. First PRs land in your repos within two weeks.
Postgres state machine, worker pool, managed DB (or your own), GitHub App, model-provider keys. The whole stack.
Nothing on your infrastructure. Workers, Postgres, audit storage, dashboards — managed.
Nothing. The pipeline runs on our infrastructure; our team operates it against the backlog we maintain with you.
You. Your team files structured issues; the pipeline processes them.
You. Your team files structured issues; the pipeline processes them.
We do, with you. Requirements intake, refinement, and acceptance criteria are part of the engagement.
Self-managed infra cost plus model-provider pass-through. No license fee for the OSS core. Self-supported.
Pilot from $35k flat for six weeks. Production engagements scoped per repo set and worker capacity; tokens pass-through with a small visible markup.
Scoped per engagement; outcome-priced rather than seat-priced. Token cost pass-through visible in the same ledger your team sees.
Community Discord, GitHub issues, the public docs. Self-managed upgrades; backwards-compatible state-machine migrations.
Two-business-day response, dedicated channel during pilots, on-call escalation for production tenants. We run the upgrades.
Embedded engagement model. Weekly delivery cadence; dedicated technical contact throughout.
Whatever your environment provides. The pipeline emits the same audit trail and ledger regardless of where it runs.
Single-tenant by default, scoped GitHub permissions, enterprise model endpoints, encryption at rest, deletion-on-request. SOC 2 Type II audit not yet completed — see /security/ for the controls.
Single-tenant; Colony staff under NDA; same enterprise model endpoints and audit trail as Cloud. Code remains yours under work-for-hire.
— (you are already running the whole thing).
Yes. Control plane managed by Colony; worker pools and code in your VPC. Private preview today; public preview Q3 2026.
Yes. Same hybrid topology as Cloud, with Colony staff operating against your backlog.
You want full control of the runtime, you have the platform engineers to operate it, and you’re comfortable with AGPL-3.0 obligations (see below).
You want the pipeline tomorrow and you don’t want to operate state machines, Postgres, and worker pools. You want a pilot scoped in two business days.
You want autonomous-pipeline output without operating the pipeline or maintaining a structured backlog yourself. Common for teams without bandwidth to build out the requirements-engineering muscle.
What in-house legal needs to know.
The Colony OSS core is licensed under GNU AGPL-3.0-only. AGPL is GPL with one additional obligation: if you offer Colony to third parties as a network service, you must make the source code (including your modifications) available to those users.
What AGPL does not require.
- Running Colony inside your company to ship your own product is fine. AGPL applies to users of the Colony service, not to users of products that Colony helped build. If you run Colony against your engineering backlog to ship a closed-source SaaS, AGPL imposes no obligations on the SaaS or its source.
- It does not infect the code Colony writes. The pull requests Colony opens against your repositories are yours, under whatever license your repository already has. AGPL is about the orchestration runtime, not its output.
- Internal use is unrestricted. If Colony is only accessible to your employees and contractors and not exposed as a network service to third parties, the AGPL-3.0 source-availability obligation does not trigger.
What AGPL does require.
- If you offer modified Colony as a service to third parties — for example, you build a product that wraps Colony, exposes a dashboard to your customers, and charges them — you must make the modified Colony source available to those users.
- Cloud users do not have this obligation. Colony Cloud is operated by Beehive Media, LLC under Beehive’s commercial rights; Cloud customers are not redistributors of the source. (See /security/ for the data-handling story.)
- Integrator shops: if you wrap Colony OSS into a productized offering you resell, the AGPL obligation applies and the integrator path is to talk to us about a commercial OEM agreement.
When in doubt, the conservative reading is correct. Bring the specifics to the pilot call; we don’t shy from clarifying license questions in writing.
Control plane ours, workers and code yours.
Hybrid is a tenancy variant available to both Cloud and CaaS engagements — not a separate deployment mode. For teams that want Colony to run the pipeline but need the agents and the source to stay inside their network. Private preview today; public preview Q3 2026.
Control plane (Colony).
The orchestration engine, the dashboards, the state machine, the audit-trail surface. Operated by us; you don’t run it.
Worker pools (yours).
The agent workers that read and write your code run inside your AWS, Azure, or GCP. Your model contracts, your egress, your network.
Code path (yours).
Your code stays where it is. Source code never transits Colony’s managed infrastructure; only metadata and orchestration events flow back to the control plane.
Self-host the core, or let us run it.
Either way, no lock-in — the pipeline is the same.